.net - 最佳实践 : 3-Tier Architecture in LINQ

Question

我正在开发一个将使用 LINQ to SQL 的个人项目 (C#/ASP.NET)。解决方案将有(到目前为止)一个 Webform 项目、一个命名空间项目(业务逻辑)和一个测试项目。到目前为止，我处于非常早期的阶段(显然处于设计阶段)。

这里有 3 层架构的范例吗？在这种情况下，DAL 似乎完全没用；感觉我应该直接从业务逻辑执行 LINQ 查询。

我还想到，如果我只保留一个常驻 DataContext 并传递它，我只需要一个打开的连接。这将有额外的好处，即一次性提交所有更改而不是细粒度地提交更改。对此有什么想法吗？

我找到了 this thread ，但它似乎描绘了一幅不完整的图画。有没有关于这个主题的深入文章？

Answer 1

你可以阅读一些领域驱动设计。

通过领域驱动设计 (DDD) 的实践，您将拥有一个丰富的“领域模型”，您可以在其中表达要解决的问题领域。
此域模型由类(和结构)组成，您可以使用这些类(和结构)对业务实体进行建模。
域模型还包含存储库。
存储库是您在域模型(和应用程序)中使用的某种抽象；存储库是数据存储的抽象。通过存储库，您可以检索实体，并且可以使用存储库来持久化实体。

在您的情况下，您的存储库可以在内部使用 Linq To SQL 与数据库对话。
但是请注意，您的存储库不应该负责管理(打开/关闭)连接和事务(启动/提交/回滚)。
为什么 ？ -> 因为存储库不知道或不知道使用它的上下文。您的应用程序或服务层(使用您的域模型和存储库的层)应该负责打开新连接并启动/提交事务。 (或者在您的情况下，打开一个新的 DataContext)。
然后，您可以将 DataContext 传递给存储库。

(Eric Evans 有一本关于 DDD 的好书，尽管有时很难破解)。