Thoughts on storing entire LINQ objects in a session?
I wanted some feedback on your thoughts on keeping whole objects in a session? For example, a customer object. Once the client logs into their dashboard, instead of resampling their data every time it is needed from the ID stored in the session, what are the pros and cons of storing the entire client object in the session?
So anytime you needed to refer to a client object, you could simply do:
Customer c = (Customer)Session["objCustomer"];
Obviously, you will need to check and have a function that updates the session. You will need to run this function in case of null session or after an update has been done.
Also, are there any other issues I should be aware of in order to do it this way? Apparently this would be much better than programming, and also make far fewer calls to the database. Anyone's thoughts?
source to share
This is not a good idea.
The main reason for this is the way ORMappers work - they don't like it when you mix objects from different contexts. And that will happen in the scenario you suggested - you have an object in session created in a different context that uses your next (and next) request. Sonner or later you will start getting exceptions.
Personally, I prefer the approach where a simple object containing the client ID (and possibly other attributes) is stored in the session (or in the user data section in the cookie) and I end up accessing the client object in a simple statement that includes the container Items
:
(production code will require a few checks here and there to be more defensive):
const string CUSTOMERITEM = "customeritem";
public Customer Current
{
get
{
if ( HttpContext.Current.Items[CUSTOMERITEM] == null )
{
int id = retrieve_the_id;
using ( DbContext ctx = GetCurrentDbContext() )
{
HttpContext.Current.Items.Add( CUSTOMERITEM, ctx.Customers.FirstOrDefault( c => c.ID == id );
}
}
return (Customer)HttpContext.Current.Items[CUSTOMERITEM];
}
}
The container of goods only lasts for the duration of one request. The above code snippet ensures that the object is loaded only once per request.
Of course, this comes at the cost of one additional request per request compared to your approach. But the advantage is that you never mess up your database contexts.
Please note that there are some business processes that do not require an object Customer
, but you can directly pass the client ID and use in requests:
public IEnumerable<Order> CustomerOrders( int CustomerID )
{
// use the customer id directly, without first loading the customer object
}
source to share
I ran into the problem described by Wiktor in another answer. I am using NHibernate and if you store objects in session you will get problems comparing them, problems with disconnected sessions, etc. However, I go ahead and save my objects in the session. I'm just making sure they all implement their own Equals () and GetHashCode () functions. This way I can compare objects from different sessions to see if they are the same object. I'm used to using obj1.Equals(obj2)
instead obj1 == obj2
.
Of course, there are always trade-offs - you get speed not to repeat the request, but you get complexity in your code. Which method is right for you depends on the specifics of your situation.
source to share
mellamokb I agree with your point in attracting the properties you need. you can do this by customizing the model and you can also disable lazy loading. Other than that, I think it's pretty safe. If we don't store all these objects as references, then there is no problem, these objects themselves will be placed in the session. the only time you can cause a problem is if both contexts are in scope.
source to share