Linq to SQL & Logical partitioning (DAL, BLL)

Question

We're going to be rebuilding one of our sites in .Net. I've read many articles and really like the idea of separating our project into a data access layer (DAL), Business logic layer (BLL), and presentation layer (we're coming from classic ASP so this is a massive step for us). I also really like Linq to SQL.

Since Linq to SQL is aimed at rapid development, is it really possible with Linq to SQL to have a DAL, BLL, and presentation layer? With Linq to SQL would the DAL return the entities or the linq code which could be possibly modified in the BLL? The relationship between the DAL and BLL with Linq to SQL seems to be a fuzzy topic with no consensus - and since this is such a big jump for us I definitely want to have a good game plan before diving into anything.

Typed Datasets seem more equipped for this, but if I can get something similar with Linq I'd go that route.

I'd like to stay away from nHibernate and other 3rd party libraries.

Answer 1

We're building exactly what you described, and we're using L2S to do it. Agreed that the relationship between the DAL and BLL is a bit fuzzy, but we have a distinct BLL and a distinct DAL. All our logic is in the BLL and all data retrieval/modification is done via calls to the DAL (using LINQ calls).

Our app uses no typed datasets. We've built entity classes to represent our objects. Now that I've spent a couple months building part of this, I don't see us (me) ever going back to datasets.

Also, I wouldn't get hung up on L2S being "aimed at rapid development". This makes it sound like a prototyping tool. We're finding it to be an industrial strength tool. This might be contrary to what Microsoft might now be saying about it, since they would rather people use EF.

Randy

Answer 2

I recommend to take one step back and look at your requirements once again.

Do you need real 3 tiers (that is physical deployment to different machines) or just logical partitioning of your application?

I made exactly this mistake on the first big Application I have written. I never needed physical 3 tiers (and will never need) but designed the application that way. The most striking consequence was that I Linq2Sql does not support disconnected Change Tracking on the entities. I used Linq2Sql Entity Base to workaround this limitation, however it violates the concept of Persistence Ignorance very badly (one always knows better afterwards, huh?).

Going real n-tiers has a lot of other implications on application architecture.

You will need message passing, data-transfer objects etc. Linq2SQL is a decent ORM, the tight integration with LINQ provides unique possibilities. Other ORMs will still need some time to catch up here. NHibernate 3.0 is a light at the end of the tunnel here. Linq2SQL is a great ORM if you have simple data models and can map in a "class per table" manner.

For disconnected change tracking (which you will need if going n-tiers) other ORMs have better support.

And at last:

(we're coming from classic ASP so this is a massive step for us)

Under these circumstances I'd be especially careful. Switching technologies is often underestimated. Even the smartest programmers on your team will make wrong decisions because they lack experience with the technology. Nonetheless it is important to go new ways and improve your skill set. Those who never fail will never suceed.

Answer 3

IMHO, LINQ to SQL is the best choice available currently. It really makes working with data painless and almost fun. :-) If you are interested in LINQ to SQL, I'd take a look at our PLINQO project. It has some great enhancements to LINQ to SQL to make it a better overall solution.

Answer 4

I would say L2S is the DAL. L2S + business logic in separate classes becomes a merged DAL+BLL, the DAL side being the L2S runtime, and the L2S-generated code (datacontext, entity classes etc).

You can still easily separate them so that the L2S-generated part, and any extensions to the entities and datacontext are in a separate DLL, and additional business logic in a separate dll/service/etc. However in many cases there is no real need to separate them.

One reason to separate into DAL+BLL when using L2S would be if you foresee that you will move to another data access technology down the road, or if you may be using more than one data access technology. Having a separate DAL with any L2S-specific stuff separate should make it easier to switch out the DAL. If you want to separate DAL+BLL for that reason, the L2S DAL-DLL should expose the entity classes, any derived classes or projection classes, and methods to get entities or collections (List etc), but keep the DataContext internal to the DAL class to avoid having L2S-specific things (L2S queries etc) trickle into the BLL.

JMHO.

---

Since others mentioned L2S tools, here is a more complete summary of what's out there: http://www.thinqlinq.com/post.aspx/title/linq-tools

Answer 5

I think with linq the dal, bll concepts no longer meaningful. So I placed linq clasees and some getters setters under 'Domain' folder under Code(Parent) folder. Then created 'Repository' classes and 'FontEnd' classes