Home/ Questions/Q 486869
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T01:32:50+00:00

I am working on architecture of mid sized web application & for my DAL

  • 0

I am working on architecture of mid sized web application & for my DAL layer i am having 3 options

1) Traditional Stored proc Based Architecture (Using NTiers Template of Codesmith)

2) LINQ To SQL (or PLINQO Template of codesmith)

3) LINQ To Entity

From above LINQ to Entity is out of reach as we need to start application very quickly and we don’t have the sufficient skillset for the same and as team has never worked on any OR/M tools it will be steep learning curve for them (This is what i read some where)

I prefer to go ahead with LINQ to SQL (But only fear is microsoft is not going to support or enhance LINQ to SQL further), from my point of view if microsoft is not going to enhance it further i am not having any issue as whatever feature i require in my project it is sufficient.

Now my issue is should i use linq to sql or should i stick to traditional architecture ?

OR else any other option is there …

EDIT : I am going to use SQL Server as database and it does not require to interact with any other database

One of the most important objective in designing DAL Layer is faster development and maintainability for future database table changes, as there are chances that field may increase or decrease in future.

Also if you feel that any ORM tool is really good and does not have steep learning curve then also we can use

Please provide suggestions

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    As you are working in medium size project, I would suggest you to use LINQ-TO-SQL because of these advantages

    Advantages using LINQ to SQL:

    •No magic strings, like you have in SQL queries
    •Intellisense
    •Compile check when database changes
    •Faster development
    •Unit of work pattern (context)
    •Auto-generated domain objects that are usable small projects
    •Lazy loading.
    •Learning to write linq queries/lambdas is a must learn for .NET developers.
    Regarding performance:

    •Most likely the performance is not going to be a problem in most solutions. To pre-optimize is an anti-pattern. If you later see that some areas of the application are to slow, you can analyze these parts, and in some cases even swap some linq queries with stored procedures or ADO.NET.
    •In many cases the lazy loading feature can speed up performance, or at least simplify the code a lot.
    Regarding debuging:

    •In my opinion debuging Linq2Sql is much easier than both stored procedures and ADO.NET. I recommend that you take a look at Linq2Sql Debug Visualizer, which enables you to see the query, and even trigger an execute to see the result when debugging.
    •You can also configure the context to write all sql queries to the console window, more information here
    Regarding another layer:

    •Linq2Sql can be seen as another layer, but it is a purely data access layer. Stored procedures is also another layer of code, and I have seen many cases where part of the business logic has been implemented into stored procedures. This is much worse in my opinion because you are then splitting the business layer into two places, and it will be harder for developers to get a clear view of the business domain.

    • 0