服务层/存储库模式

Question

我正在使用EF4的服务层/存储库/工作单元模式构建MVC应用程序。

我对逻辑有点困惑。我知道关键是要解耦系统，但我有点困惑。

因此MVC控制器调用服务来填充视图模型。那么说MVC应用程序是否与服务层相连是安全的吗？

然后，服务层调用Repository来获取和持久化对象。那么可以说服务层依赖于存储库吗？

存储库利用EF4获取数据并将数据保存到SQL服务器，因此我认为存储库依赖于EF4，而EF4又依赖于SQL Server。

工作单位都适合。

请问有什么例子吗？ 谢谢！

Answer 1

我开始将工作单元隐藏在较低层的某处，但这样做是错误的。经过一些经验，我的意见是：

• 在单一应用的情况下，控制器和较低层应该可以访问UnitOfWork。
• 如果是分布式应用程序（UI和BL位于不同的服务器上），UnitOfWork应该可以通过业务层外观（远程调用的服务层）和更低层访问。

原因是所提到的图层定义了什么是“商业交易”=什么是当前的工作单位。只有该层知道何时要提交对数据存储的更改。这样做可以实现服务组合（代码重用）。我讨论了类似问题here和here。

Answer 2

山姆，

Julie Lerman在DNR电视上做了很好的截屏，谈论this，在第9频道还有另一个屏幕，围绕EF here创建和测试存储库。

与这些相关的一般事情是在Nhibernate中创建工作单元的抽象它将是Session，在EF中将是您的上下文并将该会话或上下文传递到您的存储库中，作为您测试的一部分您可以伪造连接使用dictinary列表。

希望这些帮助。

伊恩

Answer 3

您对分层的假设是正确的。您的EF上下文是工作单元。通常，您将通过接口抽象出来，然后构造函数注入每个存储库以进行CRUD操作。另一种方法是在UoW接口上公开您的存储库（我更喜欢前者）。无论哪种方式都允许更容易地对每层进行单元测试。然后，从服务层内单次调用UnitOfWork上的Save将保留所有存储库中的所有更改。

这是a nice article on MSDN，从单元测试的角度来看UoW，但也涵盖了存储库。如果它引用了MVC控制器中的存储库，那么您将拥有另一个中间服务层。