title: LINQ to SQL - where does your DataContext live?
body: <p>I'm using LINQ to SQL in a data access object library. The library is used in both web (web application/web service) and non-web (windows service) contexts. Initially, I stored the <code>DataContext</code> on the current <code>HttpContext</code> since it permitted me to manage a fairly small unit of work (one web request) and avoided global objects in a web app. Obviously, this doesn't work in a Windows Service.</p>
  
  <p>Rick Strahl has a nice article on managing the <code>DataContext</code>'s lifetime: <a href="http://www.west-wind.com/weblog/posts/246222.aspx" rel="nofollow noreferrer">http://www.west-wind.com/weblog/posts/246222.aspx</a>. Unfortunately, I can't make up my mind on the best approach. A global <code>DataContext</code> doesn't work for reasons he mentions, a per-Thread <code>DataContext</code> seems complicated and potentially more trouble than it's worth, and a per-object instance seems fussy  - you lose some elegance when you attach the <code>DataContext</code> used to create a <code>DAO</code> to that <code>DAO</code> so it can <code>update</code> or <code>delete</code> later - not to mention, there's something unpleasantly chicken-and-eggish about the relationship.</p>
  
  <p>Does anyone have personal experience that suggests one approach is better than another? Or better yet, does anyone have a fourth or fifth approach I'm not seeing? Where is the best place to store and manage your <code>DataContext</code>?</p>