#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2008
    Posts
    10
    Rep Power
    0

    LINQ to SQL - 3 Tier Design


    Hi,

    I've just started looking at .NET's LINQ to SQL and am very impressed with it, but I have a query about how it should fit into the data access layer of a 3 tier design.

    It seems that LINQ to SQL is such a clean and concise technology that it has the potential to completely replace the DAL in an application as it does exactly the same job. Even if the DAL was to remain with LINQ to SQL as its internal workings, the DAL would be such a thin wrapper that it almost seems pointless.

    Also, as the generated entity object have the ability to update the database simply by changing their properties, surely this renders the DAL useless.. Or at least provides a path for poorly written code to bypass the DAL?

    It seems to me that the best way to use Linq to Sql is to scrap the DAL and allow the business logic layer to interact directly with the DataContext object, but this goes against every software design principle I can think of.

    I guess im just a bit confused and looking for some best practice pointers.
    Any help would be much appreciated.

    Martyn.
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    May 2004
    Posts
    3,417
    Rep Power
    887
    Originally Posted by mharris
    It seems that LINQ to SQL is such a clean and concise technology that it has the potential to completely replace the DAL in an application as it does exactly the same job. Even if the DAL was to remain with LINQ to SQL as its internal workings, the DAL would be such a thin wrapper that it almost seems pointless.
    LINQ hides a LOT of code from you. Yes, it's basically two thirds of the typical data access layer, thus cutting down on the number of lines of code you have to write, but there are sound engineering reasons for maintaining separation between your domain logic and the DAL, no matter how thin the code is that you have to write in that layer. The whole purpose of the DAL is to insure that underlying data structures can be maintained without impacting the client layer (ie, forcing a recompile of client code). To my knowledge, LINQ does not address this issue. It simply makes embedding SQL code in your C# and VB programs easier to manage.

    Originally Posted by mharris
    It seems to me that the best way to use Linq to Sql is to scrap the DAL and allow the business logic layer to interact directly with the DataContext object, but this goes against every software design principle I can think of.
    Such an extraordinary conclusion requires strong theory and data to back it up. What draws you to this conclusion?

    Originally Posted by mharris
    Also, as the generated entity object have the ability to update the database simply by changing their properties, surely this renders the DAL useless.. Or at least provides a path for poorly written code to bypass the DAL?
    LINQ is no panacea. It's just the VB/C# equivalent of embedded SQL in C/C++. There may be some applications where a DAL is not required, but then, they wouldn't need one no matter what languages you wrote them in.
    I no longer wish to be associated with this site.

IMN logo majestic logo threadwatch logo seochat tools logo