LINQ-LINQ通常应属于哪一层，DAL？

只是想收集关于LINQ应该（以及为什么）属于哪一层的不同想法和观点？

我认为LINQ应该是非常低的级别（DAL），我认为它应该被包装成BLL

我知道很多人喜欢使用LINQtoSQL生成的模型的部分可访问性，但我认为您应该有明确的利益分离（参见我在那里做了什么？）。我认为，如果您想要拥有业务逻辑，就需要将其与数据访问逻辑完全解耦

---

我认为，让它变得棘手的是，您可以在代码中任何使用System.LINQ行的地方不断链接这些LINQ扩展方法。尽管我认为LINQ属于这个定义，应该处于尽可能低的水平。当您将LINQ的使用封装在BLL中时，它还使TDD/单元测试变得越来越容易。

这取决于您想用LINQ做什么。在使用linq2sql时，我建议使用DAL，但Linq不仅仅是数据库访问。您可以使用它来操作列表、业务对象的ienumerables等等。。。Linq本身在应用程序中的任何地方都很有用。

我在传统的“数据访问层”或“数据访问对象”中使用Linq。这允许代码模块化，在一个地方提升数据代码（与在几个不同的地方剪切和粘贴相同的代码相比），并允许相对轻松地开发不同的前端。

这取决于应用程序的体系结构，表示模型与数据模型的匹配程度有很大的不同。我同意将业务逻辑操作从LINQ创建的数据对象和访问方法中分离出来。我还倾向于将所有数据级操作包装在一个manager类中，这样我就可以将数据上下文作为一个内部类。

我认为Linq的要点是它取代了DAL

---

与旧DAL等价的是所有的自动生成代码BeNHF的dBML文件+任何额外的LINQ不能由您添加。

< P>我把DATACONTRON导出的对象考虑到您的DAL层本身，LINQ只是一个非常灵活的接口。因此，我直接在业务层中使用LINQ查询。

两者都使用。DataContext是DAL，当使用设计器时，映射到SQL对象（表、视图）的自动生成的分部类可以被视为业务层的一部分。我实现了分部类，这些分部类实现了一些分部方法，以根据需要实施验证和安全性。有些业务规则不直接映射到DB对象，而是通过其他类进行处理。

LINQ=Language INtegrated querys。这是一个查询扩展，允许您查询从数据库到列表/集合再到XML的任何内容。查询语言在任何层中都很有用

---

然而，许多人将LINQtoSQL称为“LINQ”。在这种情况下，当您使用L2S时，组合BLL/DAL是有意义的，这就是您对数据库执行LINQ查询的地方。当然，这并不排除在更高层的new（Linq-to-objects）查询中对相同查询的结果执行后续查询…

我认为如果您正在执行Linq-to-Sql，您应该始终在DAL中执行。不过，如果您正在对只进行过滤的对象执行Linq，则可以使用不同的对象执行该操作，即BL层