LINQ to SQL in a three-layer architecture

Question

I am currently using a three-layer architecutre (DAL, BLL, Presentation Layer).

I am wondering how I can implement a three-tier architecture using LINQ to SQL. I do not know if LINQ should be in DAL or BLL. LiNQ seems to be a merger of both DAL and BLL.

Has anyone implemented LINQ in a three-layer architecture before?

Answer 1

I use Linq-to-SQL / XML and I believe that my application has 3 levels. The difference between the pre-Linq application is that now the level of data access is much smaller and lighter, which is actually very good!

In my old DAL, I would have methods like:

public virtual int CountCustomersInCountry(string country) { // Plug in raw SQL. } public virtual List<Customer> GetCustomersInCountry(string country) { // Plug in raw SQL. } public virtual int CountCustomersForDepartment(string department) { // Plug in raw SQL. } public virtual List<Customer> GetCustomersForDepartment(string department) { // Plug in raw SQL. } etc. etc. ad-infinitum 

Now I have the following methods:

 public virtual int Count(Expression<Func<T, bool>> where) { // Plug in Linq-to-SQL DataContext here. } public virtual T Get(Expression<Func<T, bool>> where) { // Plug in Linq-to-SQL DataContext here. } public virtual List<T> Get(Expression<Func<T, bool>> where, string orderByField, int offset, int count) { // Plug in Linq-to-SQL DataContext here. } 

To call the new DAL methods and help DynamicLinq a bit, I use:

 int countryCount = Count(c => c.Country == country); List<Customer> customers = Get(c => c.Country == country, "inserted", 0, 25); int departmentCount = Count(c => c.Department == department); List<Customer> customers = Get(c => c.Department == department, "inserted", 0, 25); 

And all this before you switch to add, update and delete, which become single-line calls with Linq2SQL! My DAL now consists of 10 methods, where previously it was easy to get up to 20-30 methods for each object that DAL looked after! I highly recommend trying a hug around you as this will really save you a lot of code.

Answer 2

LINQ-to-SQL really deals with DAL in the main - it's data access technology. However, in a simple application, nothing prevents you from transferring your LINQ-created objects to the business layer and even linking them to your user interface. Why not?

However, you need to know that in this case, you get pretty serious about LINQ-to-SQL. If this is good for your script - great, use it! This is a design decision that you need to make for yourself, in accordance with your project needs.

If the system becomes more complex, especially if your LINQ objects created from database tables do not correspond 1: 1 to your business objects, you can always use the business layer to “assemble” real business objects from your LINQ objects. a tool like AutoMapper , you can even write a lot of “monkey” code with left-right assignment :-)

On the other hand, if you are in this situation, you can also look at the ADO.NET Entity Framework, and not at LINQ-to-SQL. EF gives you many of these more advanced features, which are likely to be excessive for a small application, but can be absolutely important for an enterprise application. Things like supporting multiple database providers, such as mapping your business objects to another physical representation in your database, etc.

Mark

Answer 3

Objects created by LiNQ are usually described as business-level objects, although they do not require a higher connection to the data level than is usually desired. If, however, you have structures of a higher level than those directly represented in LiNQ, then additional controllers can manipulate then the business layer when LiNQ becomes larger than the data layer.

It really depends on the volume of objects presented in the database, as well as on the level of adhesion that you hope to achieve. Since LiNQ focuses on queries, it can over-penetrate the application.

Answer 4

I think it depends on how you look at LINQ. In normal terms, I think that he really sits in the DAL, as he closely monitors the underlying data structure. You can then abstract away from this in the BLL.

Answer 5

LINQ is not suitable for three-tier architecture. It is best suited for architecture with 2 levels.

I personally carried out my degree project in 3 levels and decided to use LINQ, but later I abandoned this idea because of many problems. The big problem is "Optimistic Concurrency Control"

Because LINQ object objects work in a related DataContext environment. therefore, during update and deletion logic. he gives errors.

Answer 6

I add entities to the DAL project and create the repository for access that I need. If you really don't need Linq to SQL objects in the BLL, you need to use the double matching method. Using the repository template simplifies Mock DAL.

Answer 7

I wrote a simple phone book using linq and 3 layers, you can download it, and if you have any questions about this, write to me.

It is available at: http://www.planetsourcecode.com/vb/scripts/ShowCode.asp?txtCodeId=7597&lngWId=10