LINQ to SQL in 3-layer architecture

Question

I currently use the 3-layer architecutre (DAL, BLL, Presentation Layer).

I am wondering how I can implement the 3 layers architecture using LINQ to SQL. I don't know whether LINQ should be in DAL or BLL. LiNQ seems the fusion of both DAL and BLL.

Does anyone implement LINQ in 3-layer architecture before?

Answer 1

I think it depends on how you are looking at using LINQ. In a normal plan I think that it really sits in the DAL as it closely follows the underlying data structure. You can then abstract on that in the BLL.

Answer 2

The objects that LiNQ creates are typically described as Business Layer objects, although they do neccesitate a higher coupling with the data layer than is typically advisable. If, however, you have higher level structures than those directly represented in LiNQ, then additional Controllers can manipulate then as a Business Layer with LiNQ becoming more of a Data Layer.

It really dependss on the scope of the objects represented in the database, as well as the level of coupling which you hope to achieve. Because LiNQ places emphasis on queryables, it can unduly permeate an application.

Answer 3

LINQ is not suitable for 3 tier architecture. it is best suitable for 2 tier architecture.

i personally doing my degree project in 3 tier and decided to use LINQ but later on i dropped this idea because of many problems. the big problem is "Optimistic Concurrency Control"

Because LINQ's Entity Objects works in connected environment of DataContext. so during update and delete logic. it gives errors.

Answer 4

I use Linq-to-SQL/XML and I consider my application to be 3 tier. The difference between a pre-Linq application is that now the data access layer is much small and lighter which is actually a very good thing!

In my old DAL I would have had 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

I now have the following sort of 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 with a little bit of help from DynamicLinq 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 thats before you get onto Adds, Updates and Deletes which become single line calls with Linq2SQL! My DAL now consists of 10 methods where as previously it was easy to get up to 20 to 30 methods for each object my DAL was looking after! I'd highly recommend trying to get your head around it as it really will save you a lot of code.

Answer 5

LINQ-to-SQL really is about the DAL mostly - it's a data access technology. However, in a simple enough app, there's nothing stopping you from passing your objects created by LINQ into the business layer and even bind them to your UI. Why not?

You need to be aware, though, that in this case, you're tying yourself fairly heavily to LINQ-to-SQL. If that's okay for your scenario - great, use it! It's a design decision you need to make for yourself, according to your project's needs.

If the system gets more complex, especially if your LINQ objects created from the database tables don't match 1:1 to your business objects, you could always use the business layer to "assemble" real business objects from your LINQ objects. With the help of a tool like AutoMapper, you can even get around writing a lot of left-right-assign "monkey" code :-)

On the other hand, if you're in such a situation, you might also want to look at ADO.NET Entity Framework rather than LINQ-to-SQL. EF gives you a lot of these more advanced features that probably will be overkill for a small app, but might be absolutely crucial for an enterprise app. Things like supporting multiple database vendors, things like mapping your business objects to a different physical representation in your database, and so forth.

Marc

Answer 6

I add the entities in a DAL project and create a repository for the access I need. If you really don't want Linq to SQL objects in the BLL you need to use the double mapping technique. Using the repository pattern makes it easy to Mock the DAL.

Answer 7

i wrote a simple phonebook using linq and 3 layer ,you can download it,and if you have any questin about that fill free to ask me.

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