kalliopi
asked on
Linq DataContext best practices...
Hi,
I have a class that is currently designed to work as follows:
Customer c = Customer.GetByID(5);
c.Name = "John Smith";
c.Save();
I'm moving to linq, so I designed my Customer class as part of a DBML file called cc. So, my code now looks like this:
cc dataCtx = new cc();
var query = from cust in dataCtx.Customers where cust.ID = 5 select cust;
Customer c = query.First();
c.Name = "John Smith";
dataCtx.SubmitChanges();
This works, as long as I CREATE the DataContext, and update the customer all in the same place. But what if I write a static method called GetByID(id) like I have right now, then all if the "Getting" code would move INSIDE of the customer class, and I'd have to save the DataContext somewhere in order for it to be available when Save() is called. Save() would need to call context.SubmitChanges() - but unless I were to save it somewhere (like in the session or something), the context would be long gone by the time Save() gets called. Certainly it's a totally different scope in the code.
Any suggestions about how to move from my current model to the new linq environment? What are the "best practice" recommendations for deal with these "DataContexts" that are needed to effectively manage all of this linq data?
Thanks.
I have a class that is currently designed to work as follows:
Customer c = Customer.GetByID(5);
c.Name = "John Smith";
c.Save();
I'm moving to linq, so I designed my Customer class as part of a DBML file called cc. So, my code now looks like this:
cc dataCtx = new cc();
var query = from cust in dataCtx.Customers where cust.ID = 5 select cust;
Customer c = query.First();
c.Name = "John Smith";
dataCtx.SubmitChanges();
This works, as long as I CREATE the DataContext, and update the customer all in the same place. But what if I write a static method called GetByID(id) like I have right now, then all if the "Getting" code would move INSIDE of the customer class, and I'd have to save the DataContext somewhere in order for it to be available when Save() is called. Save() would need to call context.SubmitChanges() - but unless I were to save it somewhere (like in the session or something), the context would be long gone by the time Save() gets called. Certainly it's a totally different scope in the code.
Any suggestions about how to move from my current model to the new linq environment? What are the "best practice" recommendations for deal with these "DataContexts" that are needed to effectively manage all of this linq data?
Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Yes, there is an Attach method on the datacontext to reattached a disconnected object. This link should explain it:
http://blogs.msdn.com/dinesh.kulkarni/archive/2007/10/08/attach-if-you-have-something-detached.aspx
if you don't want to use this then the other option is to refetch the original object and replay your changes to the fetched object.
http://blogs.msdn.com/dinesh.kulkarni/archive/2007/10/08/attach-if-you-have-something-detached.aspx
if you don't want to use this then the other option is to refetch the original object and replay your changes to the fetched object.
ASKER
Hi siturner2,
Yeah - I tried the attach method and it generates an errors that the object was loaded using a different context.
I understand the "goal" of these datacontexts, but logistically I'm fairly well confused about how to actually implement it. Specifically, the link in the first suggestion says that you should avoid caching entities loaded with a datacontext - but that seems to make the whole system fairly useless.
What if I have a method
public User GetUserByID(int id) {
MyDB db = new MyDB();
var query = from user in db.Users where user.ID = id;
return query.FirstOrDefault();
}
So - in my code somewhere I say:
User u = GetUserByID(5);
u.Password = "foo";
Now I want to save my changes. The context used to load this object has gone out of scope, is there ANY way to update the object at this point?
Sorry - but I just don't understand the recommended "logistics" of managing the context (which you must have in order to SubmitChanges). I'm sure that there is a good way to do it, but I don't see how at this point...
ej
Yeah - I tried the attach method and it generates an errors that the object was loaded using a different context.
I understand the "goal" of these datacontexts, but logistically I'm fairly well confused about how to actually implement it. Specifically, the link in the first suggestion says that you should avoid caching entities loaded with a datacontext - but that seems to make the whole system fairly useless.
What if I have a method
public User GetUserByID(int id) {
MyDB db = new MyDB();
var query = from user in db.Users where user.ID = id;
return query.FirstOrDefault();
}
So - in my code somewhere I say:
User u = GetUserByID(5);
u.Password = "foo";
Now I want to save my changes. The context used to load this object has gone out of scope, is there ANY way to update the object at this point?
Sorry - but I just don't understand the recommended "logistics" of managing the context (which you must have in order to SubmitChanges). I'm sure that there is a good way to do it, but I don't see how at this point...
ej
You can attach the updated object to a different datacontext. You need to use the Attach method with asModified as the 2nd parameter and set this to true.
ASKER
I'll give that a try - thanks.
kalliopi. what was your outcome of this. I am in the same boat. thanks scott
ASKER