Best design practices for .NET architecture with LINQ to SQL (DAL necessary? Can we truly use POCOs? Design pattern to adopt?)

Question

I was avoiding writing what may seem like another thread on .net arch/n-tier architecture, but bear with me.

I, hopefully like others still am not 100% satisfied or clea

Answer 1

Whether or not you use LINQ-to-SQL, it is often cmomon to use a separate DTO object for things like WCF. I have cited a few thoughts on this subject here: Pragmatic LINQ - but for me, the biggest is: don't expose IQueryable / Expression<...> on the repository interface. If you do, your repository is no longer a black box, and cannot be tested in isolation, since it is at the whim of the caller. Likewise, you can't profile/optimise the DAL in isolation.

A bigger problem is the fact that IQueryable leaks (LOLA). For example, Entity Framework doesn't like Single(), or Take() without an explicit OrderBy() - but L2S is fine with that. L2S should be an implementation detail of the DAL - it shouldn't define the repository.

For similar reasons, I mark the L2S association properties as internal - I can use them in the DAL to create interesting queries, but...