storing entity framework self tracking entities in asp.net session, good idea?

let us assume that I have a reusable business layer that further makes use of a data access layer that was implemented using Entity Framework 4.0. The entities returned/consumed by the business layer are self-tracking, allowing us all the goodies that come with those type of entities.

I would like to be able to store the entities I work with across post backs (on order to avoid re-querying every time). Basically let us assume I have a paged GridView with 10 items in it, and something like a DetailsView to edit those items. Every time you select a new row on the grid, the details view updates with the information of the selected row. My preference would be to only query for the entities on the initial request of the page and store it in session. Then subsequently I have a list of entities that I can work with and eventually modify and send back to the business layer with all of the changes.

I really want to use session instead of view state to reduce the page payload (self tracking entities are heavy) however I really like view state for this because of the fact that when the user navigates away from the page there is no residual effect.

Some of the things that worry me are:

1. When a user navigates away from the page to another page, the entities from the previous page are still in session. I could always do something on load of a page to do housekeeping type of work. Not sure if that's good practice.
2. I am worried about people opening browser tabs and having two views开发者_Python百科 into the same page, it seems like that might pose a problem.
3. Is this even a good approach? Seems like I am trying to have the best of all worlds, it would definitely be much easier to simply re-query on every post back for the entities and pay the 50-100ms hit of the database trip.

Your thoughts are greatly appreciated.

Take the hit of going back to the database. If your site is low trafficked enough to let you consider sticking this into the session, you'll be fine for the query hit.

There are also advantages to this, in that you could have simpler concurrency checking and you'll also not run into the problems you alude to above, of session 'cross-over' when somebody opens two tabs.

If you are going to the database then you are pretty much loosing the benefits of Self Tracking entity which has the ability to track changes when objectcontext is not around. Thus asp.net stateless scenario is a good option for STE. I think u only need to only keep one entity in viewstate that is the one that u are editing which should not be that heavy. You have the option of Session but i never liked session for the same reason you mentioned. It causes so many bugs down the road when something is left hanging.