只是想收集关于 LINQ 应该(以及为什么)属于哪个层的不同想法和观点?
9 回答
LINQ = 语言集成查询。这是查询扩展,允许您查询从数据库到列表/集合再到 XML 的任何内容。查询语言在任何层都很有用。
但是,很多人将 LINQ to SQL 称为“LINQ”。在这种情况下,当您使用 L2S 时,组合 BLL/DAL 是有意义的,这就是您对数据库执行 LINQ 查询的地方。这当然不排除在更高层的新(Linq to objects)查询中针对相同查询的结果进行后续查询......
这取决于你想用 linq 做什么。使用 linq2sql 时,我会推荐 DAL,但 Linq 不仅仅是数据库访问。您可以使用它来操作列表、业务对象的可枚举等等... Linq 本身在您的应用程序中的任何地方都非常有用。
我将您的 DataContext 派生对象视为您的 DAL 层本身,而 LINQ 只是一个非常灵活的接口。因此,我直接在业务层中使用 LINQ 查询。
两个都。DataContext 是 DAL,在使用设计器时,映射到 SQL 对象(表、视图)的自动生成的部分类可以被视为业务层的一部分。我实现了部分类,这些类实现了一些部分方法,以根据需要执行验证和安全性。一些业务规则不直接映射到 DB 对象,而是通过其他类处理。
我认为如果你在做 Linq to Sql,你应该总是在你的 DAL 中做。但是,如果您正在对只是过滤的对象进行 Linq,则可以使用不同的对象进行处理,那就是 BL 层。
我认为 LINQ 应该是非常低级的(DAL),我认为它应该被包装到 BLL 中。
我知道很多人喜欢使用 LINQ to SQL 生成的模型的部分可访问性,但我认为你应该有明确的兴趣分离(看看我在那里做了什么?)。我认为,如果您要拥有业务逻辑,则需要将其与数据访问逻辑完全分离。
我认为让它变得棘手的是您可以在代码中有 using System.Linq 行的任何地方继续链接这些 LINQ 扩展方法。同样,尽管我认为 LINQ 属于定义,并且应该处于尽可能低的级别。当您将 LINQ 的使用包装在 BLL 中时,它还使 TDD/单元测试变得更加容易。
我在传统的“数据访问层”或“数据访问对象”中使用 linq。这允许代码模块化,在一个地方推广数据代码(而不是在几个不同的地方剪切和粘贴相同的代码),并允许相对容易地开发不同的前端。
这取决于您的应用程序的架构,并且表示模型与数据模型的匹配程度有很大的不同。我同意将业务逻辑操作从 LINQ 创建的数据对象和访问方法中分离出来。我还倾向于将所有数据级操作包装在管理器类中,这样我就可以使数据上下文成为内部类。
我认为 Linq 的重点是它取代了你的 DAL。
与您的旧 DAL 等效的是 DBML 文件后面的所有自动生成的代码 + Linq 不能由您添加的任何额外代码。