Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You can think of LINQ-to-SQL as your DAL, so using it "directly from the business logic" isn't necessarily a bad thing.</p> <p><a href="http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-in-linq.aspx" rel="nofollow noreferrer">http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-in-linq.aspx</a> has some popular L2S approaches listed.</p> <p>On our project, we did not want to pass around the data context so we used a pattern similar to #3 from the above link (Ambient DataContext, see below). It had some issues, but it worked reasonably well; at least for our web project.</p> <blockquote> <p>Ambient DataContext (Currently using this)</p> <p>The idea behind ambient datacontext is that context is created for a particular thread or a httpcontext(in asp.net) as soon as there is a first call for the DataContext. Then the same context is used for that thread or request unless it is disposed manually. This is done by storing the context in the request/thread data store. The approach to this pattern is similar to static DataContext, however, separation is provided for each thread and requests. This works really well in Asp.Net, however, is again plagued by some of the problems of static context.</p> <p>Problems with this pattern:</p> <pre><code>* The context is available for manipulation at any level. And quickly becomes very hard to maintain unit of work * Portability across thread is very hard * Unit of work pattern is not transparent enough </code></pre> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload