Let’s say you are building an app that needs to be written quickly, will allow users to enter criteria for reports that it will then display, that it will run against SQL Server and the possibility of ever changing to another database (like Oracle, etc.) is remote. Do you really need a formal DAL? Can you get away with runing SQLMetal and having some Linq to SQL queries in your UI? Probably.

What if you are building an app that may get really big and end up being split across multiple physical machines? Clearly you need a formal DAL and there is no way you are going to be passing IQueryable’s around.

Linq to SQL is a new tool that we can now use to solve the problems we hit, but it is not a “one size fits all” solution.

i’m struggling with the same architectural dilemma and it seems like where ever i go to find help on it all i find is other people with the same problem but only with so-so workarounds and they all seem to differ to.

so far i’m agreeing with what progrmr said, that you simple have to pass IEnumerables up to the BAL and basically remap the result to a native format for the UI. i’m thinking im simply gonna have to create business entities and populate them from the result. seems a bit redundant though!

I think that it’s to hard to build a solid architecture with Linq To SQL ( I dont’t talk about Linq but only Linq To SQL ).

But you can see a solution in writing this :

DAL = CRUD on DLINQ with Expression in output IEnumerable, and symple type, you can use class of SQLMetal (I you want to Optimise Query maybe you need to change UpdateCheck, because i don’t find any solution to change this value in runtime)

BIZ = use class of DAL, Linq to Object and prepare Expression for DAL

UI : Use BIZ, linq to Object

It’s ok, but its not a solid architecture because you loose Entity concept, and when you try to work in SOA architecture you will to find with Entity to DataTable and true Entity !!!???? It’s not good

A good idea, it’s to use a best linq provider to access DataBase because DLinq is nearest SQLServer, and that force to have a bottom up vision.

Why would we write static-named methods for all possible queries we have to make on our Domain Model ?
Linq to SQL is bringing DDD to the mass … and it is indeed a problem if you still think in terms of ‘layers’ instead of ’services’.

In DDD, your Domain Model contains data structure AND business logic. The Repositories abstract your domain model from the ‘boiler-plate data access code’. Concerning the Service Layer, you don’t actually need one. If you have one, it can be very thin, just acting as a bridge/facade.

See the ‘BackgroundMotion’ website architecture as a living example of those concepts. Kudos to Andrew ;o)

I also see the point of one poster above that the presentation layer cannot/should not communicate with the DAL – meaning that the BLL is going to have to handle results returned to it and return to the presentation a native format that doesn’t worry about the underlying entity classes.

Let’s take an example, you have a customer, account and reporting service for instance and a single database. You can design try to assign each table to a specific service, having one DAL per service but each service is able to use the DAL of the other services. That’s not “pure” SOA but it’s reasonable to do this in my opinion.

But this also implies that your business entities (the ones returned by the DAL) also need to be shared between services as they are interconnected (a client has a list of accounts for instance). But this starts to defeat the purpose of services. Depending on the service, I would like to design my entities with only the data related to the domain covered by the service but then it leads to a lot of duplicated code describing the entities.

Does someone have some insight/experience with this problem ?

I do think that it will be very handy to be able to query against objects though.