服务层/存储库模式 [英] Service Layer/Repository Pattern

问题描述

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

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

所以MVC控制器调用服务来填充视图模型。那么可以肯定地说，MVC应用程序与服务层耦合？

然后服务层调用Repository来获取并保存对象。然后可以安全地说服务层依赖于存储库？

存储库利用EF4获取和保留数据到SQL服务器，所以我认为存储库依赖在EF4上又依赖于SQL Server。

工作单位在哪里都适合。

有什么例子吗
谢谢!!

解决方案

我开始隐藏下层工作单位，但这是错误的做法那。经过一些经验，我的意见是：

• 在单层应用程序的情况下，UnitOfWork应该由Controller和下层访问。


• 如果分布式应用程序（UI和BL在不同的服务器上），UnitOfWork应该可以通过业务层门面（用于远程调用的服务层）和较低层来访问。

原因是提到的层定义什么是业务事务=什么是当前工作单位。只有这个层才知道什么时候要对数据存储进行更改。这样做可以使服务组合（代码重用）。我讨论了类似的问题此处和此处。

I am building an MVC app using the Service Layer/Repository/Unit of Work pattern with EF4.

I am a bit confused on the logic. I know the point is to decouple the system, but I am a little confused.

So the MVC Controllers call on the Services to fill the View Models. So is it safe to say the MVC App is coupled to the Service Layer?

Then the Service Layer calls on the Repository to get and persist objects. Is then safe to say the Service Layer is dependent to the Repository?

The Repository the utilizes EF4 to get and persist data to SQL server, so I would assume the Repository depends on EF4 which in turn depends on SQL Server.

Where does the unit of work all fit in.

Any examples please? Thanks!!

解决方案

I started with hiding Unit of work somewhere in lower layer but it is wrong way to do that. After some experience my opinion is:

• In case of monolitic application UnitOfWork should be accessible by Controller and lower layers.
• In case of distributed application (UI and BL are on different servers) UnitOfWork should be accessible by business layer facade (service layer for remote calls) and lower layers.

The reason is that mentioned layers define what is the "business transaction" = what is current unit of work. Only this layer knows when it wants to commit changes to data store. Doing it this way allows service composition (code reuse). I discussed similar question here and here.

这篇关于服务层/存储库模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！