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

Question

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

Answer 1

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

但是，很多人将LINQ to SQL称为“LINQ”。在这种情况下，当你使用L2S时，组合的BLL / DAL是有意义的，那就是你对数据库进行LINQ查询的地方。这当然不排除对更高层中的新（Linq到对象）查询中的相同查询的结果进行后续查询...

Answer 2

这取决于你想用linq做什么。当使用linq2sql我推荐DAL，但Linq不仅仅是数据库访问。您可以使用它来操作列表，业务对象的可能性等等...... Linq本身在您的应用程序中随处可用。

Answer 3

我将您的DataContext派生对象视为DAL层本身，而LINQ只是一个非常灵活的接口。因此，我直接在业务层中使用LINQ查询。

Answer 4

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

Answer 5

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

Answer 6

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

我知道很多人喜欢使用LINQ to SQL生成的模型的部分可访问性，但我认为你应该清楚地分离兴趣（看看我在那里做了什么？）。我认为，如果您要拥有业务逻辑，则需要将其与数据访问逻辑完全分离。

我认为让你变得棘手的是你可以在你的代码中使用System.Linq行的任何地方继续链接那些LINQ扩展方法。虽然我认为LINQ属于定义，但应该处于尽可能低的水平。当你在BLL中包装LINQ时，它还使TDD /单元测试变得更加容易。

Answer 7

我在传统的“数据访问层”或“数据访问对象”中使用linq。这允许代码的模块化，在一个地方促进数据代码（相对于几个不同的地方切割和粘贴相同的代码），并允许相对容易地开发不同的前端。

Answer 8

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

Answer 9

我认为Linq的观点是它取代了你的DAL。

与您的旧DAL相当的是所有自动生成的代码都是DBML文件+ Linq无法添加的任何额外内容。