7

我总是在所有地方插入我的 Linq2SQL 查询，几乎在所有地方的每个班级中。

我想知道您将 Linq2SQL 查询放在哪里的策略？

您是将它们放在单独的数据层类中还是将它们存储在各处使用它们的地方？

我认为我需要更改 Linq2SQL 查询的策略并将它们存储到单独的 DataLayer 类中。我认为，如果我要能够有效地进行 TDD 并遵守依赖注入和 Solid 原则，这是必须的。

4

9 回答 9

6

我将所有 LinqToSQL 调用完全包装到一个 DAL 中。我的网站和业务层不知道我正在使用的持久性框架。这样，如果 LinqToSql 真的死了，或者我决定要使用一个全新的框架，我就不必寻找我进行数据库调用的所有地方。

它还有助于可重用性。我可以在使用相同数据库的其他项目中使用相同的业务或 DAL。

于 2009-02-01T16:09:17.550 回答
5

LINQ 是一种语言结构。它所需要的只是您的 DAL 将您的实体公开为 IEnumerable 或 IQueryable，并且您可以对它使用 LINQ。您的 DAL 可以基于 LINQ2SQL 或 LINQ2Entities 或您自己的自定义代码——只要它正确地公开您的实体即可。如果您使用 LINQ2SQL，您将获得一些优势，例如延迟查询执行，但这并不是绝对必要的。我认为避免在 DAL 之外使用 LINQ 毫无意义。如果我想用其他不基于 LINQ2SQL 的东西替换 DAL，我可以。只要我维护基于 LINQ 的代码所期望的接口，我就可以了。

编辑：对我来说，最重要的是，在他们到达 DAL 之前，它们不是 LINQ2SQL 查询，它们只是 LINQ。LINQ 不会从语言中消失，除非它被更好的东西取代。使它成为 LINQ2SQL 的原因是 DAL 是用 LINQ2SQL 实现的。我的其余代码不知道（或关心）事实如此。它可以是 LINQ2Objects 或 LINQ2Entities 或...

于 2009-02-01T16:15:56.617 回答
3

将我所有的 Linq2SQL 查询放入一个单独的类中，可以在测试访问它的业务对象时轻松地将其替换为“模拟/存根”。

还是我错了？

于 2009-02-01T16:02:07.050 回答
1

如果您认为您的 LINQ 查询是 LINQ2SQL 查询，那么您会稍微忽略这一点。

您有 LINQ 查询。您的业​​务层通过对数据层（数据上下文）进行 LINQ 查询来访问数据层。LINQ2SQL 是允许 LINQ 查询访问 SQL Server 的组件。

这是一个严重的过度简化，但一般来说，如果您将所有 LINQ 隐藏在业务层之外，您并没有真正从其存在的理由中受益。

如果 LINQ2SQL 不允许您将 DB 模式抽象到您喜欢的程度，那么您应该考虑改用实体框架。

于 2009-02-01T15:52:07.210 回答
0
  • 我使用外部映射。
  • 域类位于单独的程序集中。
  • 数据上下文位于助手程序集中。
  • 我有许多 xml 映射文件

当我需要访问数据库时，我使用连接字符串（哪个数据库）和一个映射文件（要映射哪些表）来实例化 Helpers.DataContext。

这可以很好地分离关注点。

于 2009-02-01T16:16:27.893 回答
0

我个人在其中创建“基本”查询并公开 IQueryable。

在我的业务对象中，我喜欢返回具体的结果，所以我通常只在内部创建 QueryByExpression 风格的方法，然后创建方法存根，我可以在其中传递我的条件，并在我处理查询的方法中，从数据库，并返回结果的 IEnumerable，而不是让应用程序的其余部分需要上下文或任何东西。

但是，就像上面许多人所说的那样，我不得不同意——将您的 IQueryable 暴露给您的代码并不可怕，它只是让您与您的 Linq2Sql 的东西有更多的联系。

如果您不介意创建公开方法但不公开 IQueryable 类型的业务对象，我觉得这样更好，但设置和配置业务对象更加繁琐。它也更容易测试我的感觉，但这只是我。还可以实现可重用性，如果你修复了一个错误，那么 2 年后它不会出现在你的代码中的 30 个不同位置。

只是我的2美分。

于 2009-08-14T01:12:46.087 回答
0

我不一定要创建单独的业务对象，因为这是 LINQ2SQL 的重点，您将重新创建很多使 LINQ2SQL 如此出色的东西。

但是，我建议创建一个包含静态类的类库，其中包含 L2SQL 代码。这为您提供了能够替换单个程序集以更改业务逻辑的优势。此外，如果您有额外的方法来访问数据，那么您的静态类是该逻辑的好地方。

但是，如果您的需求有点复杂并且您不介意创建自己的映射，我会同意 Florian。

于 2009-09-16T19:54:11.507 回答
0

我的最新项目使用 ASP.NET MVC 框架和 LINQ-to-SQL。出于这个原因，我的数据层非常依赖存储库模式。由于这是我的第一个 LINQ-to-SQL 项目，因此数据库模式在单个 DataContext 类中表示。随着后续项目的出现，我可以分离出常见的 DataContexts 以供重用。

我创建了一个接口，其中包含我计划为特定存储库实现的所有签名，该存储库通常表示单个复杂对象。基于该接口，我实现了两个类：一个用于生产，一个用于测试。我所有的 LINQ-to-SQL 查询都保存在存储库类中。在我的控制器代码中，我访问我的数据访问方法的存储库。我的观点中不包含查询；我使用自定义视图模型类，这些类使用存储库方法填充到控制器中。

于 2010-01-06T19:03:07.627 回答
0

我在 DAL DLL 中使用了 Linq2SQL。我喜欢关注点的分离以及任何其他需要访问相同数据库的站点或应用程序，您可以重用 DLL 中的相当多的代码。所以所有的 Linq2SQL 都存储在这个 DAL 中。现在对于 Linq 本身，我根据需要在我的服务和表示层中使用它。

Linq2SQL DLL 布局

创建映射 .dbml 文件以将 SQL table.columns 映射到 Linq 目录 (SqlRepository)

编写与服务层类匹配的 sql 存储库类并使用正确的 Linq 目录类。

为每个 sql 存储库类添加了接口，以便服务层直接使用接口

编写了 sql 存储库类与服务层来回传递的业务模型。

于 2010-01-06T19:16:43.280 回答