LINQ - what layer should LINQ go to, DAL?

Question

just wanted to gather different ideas and perspectives as to which layer should (and why) LINQ get into?

Answer 1

it depends on what you want to do with linq. when using linq2sql i`d recommend DAL, but Linq is more than just access to the database. you can use it to manipulate lists, ienumerables of business objects, and so on ... Linq itself can be useful everywhere in your application.

Answer 2

LINQ = Requested Languages. These are query extensions that allow you to query any of the databases for lists / collections in XML. The query language is useful at any level.

However, many people refer to LINQ in SQL as "LINQ". In this context, the combined BLL / DAL makes sense when you use L2S and that where you make LINQ queries to your database. This, of course, does not preclude the execution of subsequent queries against the results of the same queries in new (Linq to objects) queries in higher layers ...

Answer 3

I consider your DataContext object to be my DAL layer, and LINQ is a very flexible interface. Therefore, I use LINQ queries directly at the Business level.

Answer 4

I. DataContext is a DAL, and when you use the constructor, automatically generated partial classes that map to SQL objects (tables, views) can be considered part of your business layer. I implement partial classes that implement some partial methods to provide validation and security as needed. Some business rules do not bind directly to database objects and are processed through other classes.

Answer 5

I think that if you do Linq in Sql, you should always do this in your DAL. However, if you do Linq for objects where you just filter by playing with another object, you can do this with a BL layer.

Answer 6

I think LINQ should be very low level (DAL), and I think it should be wrapped in BLL.

I know that many people like to use the partial availability of LINQ to SQL models, but I think you should have a clear separation of interests (see what I did there?). I think that if you have a business logic, you need to completely separate it from the data access logic.

I think this is difficult to do because you can keep the chain of these LINQ extension methods anywhere you have the System.Linq line in your code. Again, although I believe that LINQ belongs to the definition and should be at the lowest possible level. It also makes TDD / Unit Testing a lot easier when you port using LINQ to BLL.

Answer 7

I use linq in the traditional "data access layer" or in "data access objects". This allows you to modulate the code, promotes the data code in one place (against cutting and pasting the same code in several different places) and allows you to easily develop another interface.

Answer 8

It depends on the architecture of your application, and it is of utmost importance how the presentation model matches the data model. I agree with the separation of business logic operations from data objects and access methods created by LINQ. I also tend to wrap all data-level operations inside the manager class, so I can make the data context an inner class.

Answer 9

I think the point of Linq is that it replaces your DAL.

Equivalent to your old DAL - this is all automatically generated code with DBML files + everything Linq cannot do for you.