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

时间:2009-01-26 21:46:59

标签: .net linq-to-sql architecture n-tier-architecture

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

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

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

我找到了this thread,但它似乎描绘了一幅不完整的画面。是否有关于这个主题的深入文章?

4 个答案:

答案 0 :(得分:5)

你可以在领域驱动设计上阅读一下。

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

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

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

答案 1 :(得分:4)

您可以将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背后的想法是,只要第一次调用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

答案 2 :(得分:1)

你应该小心你的术语。当你说LINQ你的意思是Linq-to-sql,当你说3层时,通常意味着你在谈论一个有3个独立机器的部署场景。我不确定这是不是你的意思。

使用像linq-to-sql这样的ORM工具时,三层架构仍然是一个好主意。 DAL只是存储查询逻辑的地方。将查询从业务层中删除是一个好主意,因为查询是持久性问题,而不是业务逻辑问题。

管理数据上下文的常用技术是每个请求都有一个数据上下文。

关于该主题的其他文章,您可以查看任何ORM工具的架构指南 - linq-to-sql也不例外。寻找有关NHibernate架构的文章。

答案 3 :(得分:0)

在这种情况下,LINQ to SQL库是您的DAL,而不是从业务层进行传统的API调用(例如DAL.GetObjectById(id)),您可以灵活地向DAL提出更具表现力的请求。

如果您有其他需求,例如您自己的LINQ提供程序连接到非MSSQL数据支持,那么您将实现自己的DAL。

另外,对于DataContext,不建议将单例模式与“一个驻留DataContext”一起使用。 DataContext对象应该表示单个逻辑事务,无论对您的应用程序意味着什么。 (从http://weblogs.asp.net/despos/archive/2008/03/19/more-on-datacontext-in-hopefully-a-realistic-world.aspx转述)