Steve Michelotti

A .NET Developer's Toolbox

  Home  |   Contact  |   Syndication    |   Login
  201 Posts | 0 Stories | 1110 Comments | 51 Trackbacks


View Steve Michelotti's profile on LinkedIn

profile for Steve Michelotti at Stack Overflow, Q&A for professional and enthusiast programmers

Google My Blog

What I'm Reading:

Shelfari: Book reviews on your book blog

Tag Cloud


Post Categories



In a previous post here, I discussed implementation of Attaching Linq entities to a DataContext.  In that post, I showed an implementation of utilizing a Detach() method that I originally based on this post here.  The implementation boils down to the need to reset EntityRef<> references back to their default - otherwise, it will try to attach the parent objects (which is often not the goal of your code as this is often just reference data). Consider the DataContext below:

The fundamental problem here is that State and AddressType should NOT be in this data context at all!  Doing so causes the auto-generated classes to include EntityRef<> references to them in the Address class.  In my actual Address business objects, all I really care about it the StateID.  The database takes care of enforcing the foreign key to the State table.  My application does need to query the State table directly for populating the State drop down list but it should be in its own data context.  So I need to have 2 different DataContexts.  The first should contain only Contact and Address from the diagram above. The second (call it ReferenceDataContext for my State and AddressType reference data) should simply look like this:

Bottom line: don't stuff everything in your database into a single DataContext dumping ground - be mindful of the context.  If you have a DataContext where the only items you're updating contain business entity and not their reference data then do not include them - this is much simplier and allows you to avoid having to write Detach() methods at all!

posted on Thursday, December 27, 2007 8:48 PM


# re: Be mindful of your DataContext's "context" 1/13/2008 9:56 AM wahy
hi steve, nice blog and articles,

so in my dbml class, should I only make association between two tables only if they have a one to many relationship e.g. your contact object can have many addresses (address collection)?

other question I tried to seperate ui, bl, dal in my app using linq and do the submitchange, insert, etc in dal, so bl just call another public method in dal (i use partial class of the datacontext). does this make sense? or should i just do submitchange, etc in bl? as you did it in your ContactManager class.


# re: Be mindful of your DataContext's "context" 1/13/2008 12:37 PM Steve
wahy - In regards to your first question, yes, I'd say that when you have a relationship (such as a one to many), that is the appropriate time to make an association in your data context. The key above is that you might have additional associations in your database (as enforced by your foreign keys) but you're not necessarily going to need them in your business layer because you're never updating the reference data at the same time as your business objects.

In terms of your second question, I'm not sure I'm following your example exactly. Because of Linq, you won't require the same type of separation that you've traditionally had between your BL and DAL. In the example above, the ContactManager essentially IS your DAL (but Linq makes writing the DAL very simple). In general, I still prefer separating the DAL and BL in this way. That is, I prefer my BL objects to not have Save() methods (for example) directly on them - I prefer to have a DAL class (e.g., ContactManager) for this. Hope this helps.

# re: Be mindful of your DataContext's "context" 1/13/2008 4:30 PM wahy
thanks for your response. LINQ is my first ORM tool, since basically i'm more UI developer, so would it be ok if i have dbml file for each table? and of course dbml with two table if necessary.

# re: Be mindful of your DataContext's "context" 7/2/2008 8:05 PM LukkhaCoder
If we have a Manager class for each entity, won't you end up having a lot of Manager classes?

# re: Be mindful of your DataContext's "context" 1/6/2010 2:13 PM Jarrod
I believe by setting DeferredLoadingEnabled = false on your DataContext when you retrieve the entities originally you can Attach to the new DataConext with no problems.

# re: Be mindful of your DataContext's "context" 3/22/2010 11:47 AM Everett Comstock

Do you recommend setting the DataContext's DeferedLoadingEnabled attribute to false to address this issue? Can you give an example as to why or why not? Also, if splitting up the DataContext's as you recommend, can you envision a scenario where you may have one context to "Select" entities, and another to "Save", "Update" and "Delete" entities?


# re: Be mindful of your DataContext's "context" 3/25/2010 2:06 PM Steve
@Everett - In this case, I don't believe that the DeferredLoadingEnabled will make a difference. Also, I would probably try to avoid duplicate data contexts if I could avoid it.

Also, have a look at this link:

# re: Be mindful of your DataContext's "context" 8/4/2012 10:50 AM Don
I have made it work by deleting the association lines in the dbml diagram and making sure that my tables have a timestamp.

Post A Comment