Guy Barrette

Check out This article on CodeProject

www.codeproject.com/.../vs2008messageboard1.aspx

It is a good example of how to create a linq DataContext that maps your BAL objects to tables using an xml file.

You can also take a look at this sample

weblogs.asp.net/.../building-an-n-layer-asp-net-application-with-linq-lambdas-and-stored-procedures.aspx

This is also a decent approach seperating the layers while using Linq to SQL.

Don't worry. I am trying to figure the same thing out now. Maybe the ASP.NET team could write a quick sample app to use as a reference.

Hi,

I was facing the same problem when I started with DLINQ (LINQ to SQL Classes). I also send the question to the authors of "LINQ in Action" and they told me that LINQ can only be used when creating Rapid Applications. This means you cannot layer your application using LINQ.

Off course, you can generate your entity classes and then copy paste in the BLL layer but that would not make any sense and will be considered a constant change?

What does POCO stand for?

use NHibernate, or even linq to nhibernate, your pain will ease

Guy you can do this if you use LINQ to SQL as your DAL. You can keep the data context on your business objects and pass the POCO objects out. This should work fine as long as you don't disconnect the data context (ie. keep a reference to the business object around). This obviously won't work in a truly disconnected environment in which case you shouldn't have connected objects anyway right? There'd be a messaging layer in the middle and the synching is up to you.

LINQ to SQL definitely has issues with disconnected scenarios and if you're using to something like nHibernate LINQ to SQL is going to really screw with you because in LINQ to SQL entities are always indirectly bound by the DataContext which contains all the change state.

I've written about a business layer with LINQ to SQL here and this might help:

www.west-wind.com/.../160237.aspx

But there's no doubt - LINQ to SQL is NOT a one stop solution for data access. There are a number of problems with it with the disconnected scenario being the most obvious. However, if it fits - pure Web, or pure desktop apps or apps that only use minimal cross physical boundaries then LINQ to SQL can be pretty sweet because of the LINQ functionality that is available on the data which can reduce a ton of code and provide a lot of flexibility in how data passed out of the middle tier can be used.

In the future LINQ hopefully will be common with other ORM systems that are more powerful, but for now LINQ to SQL is it if you want LINQ data massaging (for better or worse).

POCO = plain old CLR objects (or an '80s country/rock band)

I ran into this same question, my answer that works 100%?  I went back to NHibernate and the Repository Pattern.

Interesting blog post describing some of the shortcomings of ASP.MVC Anotherblog post, this time about

As far as I can see, LINQ to SQL is a useful tool for developing prototypes and throwaway apps but isn't suitable for the kind of layered apps you're talking about. LINQ to Entities sounds like it will be the answer to what you're looking for.

The article below covers how to use Linq-to-sql with the repository pattern.

www.codeproject.com/.../linqrepository.aspx

You are correct, overall. The DataContext forces keeping a context open to add all the data access sweetness. LINQ is a viable option for many things, but I find that it is better for manipulating objects that adhere to IEnumerable than to get data out of a database.

There are other LINQ to SQL implementations that are disconnected, but I have yet to genericize one to use <T>.