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

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

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

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

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

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

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

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

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