More on DataContext in (hopefully) a realistic world
A comment from Bigyan to my DataContext article on DotNetSlackers yesterday made me think that I probably had to put my thoughts down a little more explicitly. The question that Bigyan poses is expressed in detail in this post of his and revolves around the best way of dealing with DataContext in multi-tier apps. My experience suggests that you use a new instance of the DataContext for each unit-of-work you need. The DataContext is a lightweight object to instantiate/dispose just for this. Can't find the link but somewhere on MSDN I've found a note (documentation) along the following, quite explicit, guidelines:
In general, a DataContext instance is designed to last for one unit of work however your application defines that term.
It is not recommended to maintain a DataContext live for more such as stored in a singleton object. Likewise, you don't have to pass it around, because it is not exactly a light object once in use with data attached: data + tracking info + mapping info. If you find it cumbersome to write new DataContext at each step, you can use a bit of abstraction and perhaps a Repository pattern. One more thought about not passing it around tiers and layers. You don't reuse the data context; you'll reuse the data you attach to it. So it makes sense to cache data somewhere and using distinct data context to do manipulation. On the new data context, you just attach any desired data. Yes, again, using the DataContext should be kind of using an ADO.NET connection: you use always new DbConnection objects but reuse command text and parameters. You never keep a connection open for a long time and don't pass it around tiers.
My two (euro)cents.