最佳实践:LINQ中的3层架构

Question

我正在开发一个将使用LINQ to SQL的个人项目(C#/ ASP.NET).解决方案将具有(到目前为止)Webform项目,Namespace项目(业务逻辑)和Tests项目.到目前为止,我处于早期阶段(显然处于设计阶段).

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

我也想到,如果我只保留一个驻留的DataContext并传递它,我只需要一个打开的连接.这将有额外的好处,即一次性提交更改而不是粒度.有什么想法吗？

我找到了这个帖子,但它似乎描绘了一幅不完整的画面.有没有关于这个问题的深入文章？

Answer 1

您可以在领域驱动设计上阅读一些内容.

通过域驱动设计(DDD)的实践,您可以拥有丰富的"域模型",您可以在其中表达要解决的问题域.此域模型由用于为业务实体建模的类(和结构)组成.域模型也包含存储库.
存储库是您在域模型(以及应用程序中)中使用的某种抽象; 存储库是数据存储区的抽象.通过存储库,您可以检索实体,并且可以使用存储库来持久保存实体.

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

(埃里克埃文斯有一本关于DDD的好书,虽然不时难以破解).

Answer 2

您可以将 LINQ-to-SQL 视为您的 DAL，因此“直接从业务逻辑”使用它不一定是坏事。

http://dotnetlog.com/archive/2008/03/18/best-practice-and- effective-way-of-using-datacontext-in-linq.aspx 列出了一些流行的 L2S 方法。

在我们的项目中，我们不想传递数据上下文，因此我们使用了类似于上述链接中的 #3 的模式（Ambient DataContext，见下文）。它有一些问题，但运行得相当不错；至少对于我们的网络项目来说是这样。

Ambient DataContext（当前使用这个）

环境数据上下文背后的想法是，一旦第一次调用 DataContext，就会为特定线程或 httpcontext（在 asp.net 中）创建上下文。然后，除非手动处置，否则相同的上下文将用于该线程或请求。这是通过将上下文存储在请求/线程数据存储中来完成的。此模式的方法类似于静态 DataContext，但是为每个线程和请求提供了分离。这在 Asp.Net 中运行得非常好，但是，再次受到静态上下文的一些问题的困扰。

这种模式的问题：

* The context is available for manipulation at any level. And quickly becomes very hard to maintain unit of work
* Portability across thread is very hard
* Unit of work pattern is not transparent enough