Attention: We are retiring the ASP.NET Community Blogs. Learn more >

LINQ to SQL - Stunned!

[Looking for opinions, links, articles and so on]

How do you implement LINQ to SQL in a classic 3-tiers (presentation, BAL, DAL) app?  A simple question, right?

So, if I create my LINQ to SQL DataAccess classes in a DAL, this is where the transport objects will reside.  I usually create a layer just for that so each layer can reference those objects.  Now, the presentation layer must reference the DAL directly.  Yuck!

OK, so let's return POCOs to the presentation layer instead.  Well, I'm losing all the change tracking stuff provided by LINQ to SQL.  Yuck!

What if I need to expose my BAL layer as a set of WCF services?  Well, I'm also losing the change tracking.  Yuck!

And what if I want to data bind my grid?  Using the designer, I need to point to the DataClasses sitting in the DAL.  Yuck!

OK, I'll lose the change tracking stuff.  Now I'll have to reload each record before saving it?  Yuck!

The way I see it, the only way you can possibly use LINQ to SQL is if you develop your app in a single layer.  I must be wrong.  I must miss something.  This can't be real.  Stunned!

 

14 Comments

  • Check out This article on CodeProject
    http://www.codeproject.com/kb/aspnet/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

    http://weblogs.asp.net/dwahlin/archive/2008/02/18/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

  • 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.

  • Thanks everyone for your comments and links. They are very useful.

  • 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.

    http://www.codeproject.com/KB/architecture/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 .

  • It works fine if you don't use the Linq magic. (that's sarcasm)

    No question Linq to SQL was written for developers of typical web sites and directly connected winforms. I don't mind saying - right or wrong, that 90% of the applications out there.

    If THOSE applications could have used Linq to SQL - imagine what a simplified maintenance situation we would have today.

    This is no Entity Framework - and from what I read Microsoft's Entity Framework is no Entity Framework either. What's the deal Microsoft?

  • Been learning LINQ to SQL for a few weeks only and I've been trying to figure out if there's really a need to create another layer of abstraction for our DBML file and place it on a DAL/BAL object. Isn't it being redundant?

    It feels bad also that everytime we make changes on our backend objects bound to an existing DBML it doesn't automatically refresh it's schema

  • I have been researching this so called idiom “LINQ to SQL” pretty heavily. I have spoken with several professionals as well… It seems no one really knows WTF to make of it.

    It looks like t Microsoft (or whoever) is trying to make the new paradigm; a BLL-DAL object pattern.

    Even if you do get it into an “n-tier” solution there is a bigger issue… Performance.

    From my own testing “LINQ to SQL” is damn slow compared to the muscle of a sproc on the box (with traditional n-tier). In fact, I can type faster than the auto-complete I connected with “LINQ to SQL” (which is shameful considering how bad I type).

    I agree with the earlier comment;” LINQ to SQL” is really good for “proof of concept” not production.

    If there is a best practice or pro design pattern for “LINQ to SQL” (which I doubt) no one is stepping up.

    I think my college professor said it best; this is Microsoft’s typical way of marketing .NET; showing everyone you can crank out an application in 10 minutes. DBML? Great another blotted monolithic object.

    LINQ to Entities is a whole other story… With a Lambda expression it is killer fast (blows for, foreach, etc.. out of the water).

    Cheers

Comments have been disabled for this content.