在业务层拥有“unitOfWork”的最佳项目模式

时间:2011-12-15 14:46:30

标签: linq linq-to-sql design-patterns unit-of-work atomicity

我在C#.NET中有一个桌面项目,其结构为:gui,业务和数据访问层。每个业务层类代表数据库的实体。我正在使用linq访问数据库。但是今天实施项目的方式不允许以原子方式进行许多操作,我需要在业务层中完成这项工作。

我搜索了一些设计模式,发现unitOfWork在相同的上下文中提交了数据层中的所有操作,并且在提交了所有更改之后。这将使操作成为原子。但问题是我想要做的操作之前需要进行验证,这意味着,不是从数据层调用方法,而是需要从业务层调用一个方法来验证之前的方法。业务层中的这个调用将创建另一个unitOfWork,并因此创建另一个上下文,打破我正在尝试的更大操作的原子性。

问题是:在同一个linq上下文中从业务层调用业务层的一个或多个方法的最佳项目模式是什么?

1 个答案:

答案 0 :(得分:1)

这样做的一种方法是:

  • 在业务层之上创建服务层。
  • 此服务层由2个服务组成(可以是真正的WCF服务,也可以只是常规的C#类):一个用于阅读,一个用于写入。
  • 读取服务不是事务性的,它只包含执行查询的方法(即读取数据)。
  • 写作服务是交易性的;它的所有方法都要么创建一个事务上下文,要么遵循工作单元模式。
  • 写作服务在其业务层执行C / U / D操作之前访问读取服务以进行验证。