Best Practices: 3-Tier Architecture in LINQ

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 could read up a bit on Domain Driven Design.

With the practice of Domain Driven Design (DDD), you have a rich 'domain model', in where you express the problem domain that you want to tackle. This domain model consists of classes (and structs) with which you model your business entities. The domain model also consits of repositories.
A repository is some kind of abstraction that you use in your domain model (and in your application); The repository is an abstraction of your datastore. Through the repository, you can retrieve entities, and you can use the repository to persist entities.

In your case, your Repositories could use Linq To SQL internally to talk to the database. Note however, that your repository should not be responsible to manage (open/close) the connection and the transaction (start/commit/rollback) though. Why ? -> because the Repository has no knowledge or notion of the context in which it is used. It is your application or service layer (the layer that uses your domain model and hence your repository) that should be responsible for opening a new connection and starting / committing transactions. (Or in your case, open a new DataContext). You could then pass the DataContext to the repository.

(Eric Evans has a great book regarding DDD, albeit a hard nut to crack, from time to time).

Answer 2

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