Question

I’m working on a personal project (C# / ASP.NET) that will use LINQ to SQL. The Solution will have (so far) a Webform project, a Namespace project (business logic), and a Tests project. I’m in the very early stages so far (clearly in Design phase).

Is there a paradigm for 3-Tier Architecture here? It seems like the DAL is entirely useless in this case; feels like I should be performing the LINQ query directly from the business logic.

It also occurs to me that if I just keep one resident DataContext and pass that around, I would only need the one open connection. This would have the added benefit of committing changes all at once instead of granularly. Any thoughts on that?

I found this thread, but it seems to paint an incomplete picture. Are there any in-depth articles on the subject?

Answer 1

You can think of LINQ-to-SQL as your DAL, so using it ‘directly from the business logic’ isn’t necessarily a bad thing.

http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-in-linq.aspx has some popular L2S approaches listed.

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.

Ambient DataContext (Currently using this)

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.

Problems with this pattern:

* 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