服务层/存储库模式
我正在使用 EF4 的服务层/存储库/工作单元模式构建一个 MVC 应用程序。
我对逻辑有点困惑。我知道重点是解耦系统，但我有点困惑。
因此，MVC 控制器调用服务来填充视图模型。那么可以肯定地说 MVC 应用程序耦合到服务层吗？
然后服务层调用存储库来获取并持久化对象。那么可以肯定地说服务层依赖于存储库吗？
存储库利用 EF4 获取数据并将其保存到 SQL Server，因此我假设存储库依赖于 EF4，而 EF4 又依赖于 SQL Server。
工作单元都适合在哪里。
有什么例子吗？ 谢谢！！
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!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您对分层的假设是正确的。您的 EF 上下文是工作单元。通常，您将通过接口将其抽象出来，然后将构造函数注入到每个存储库中以进行 CRUD 操作。另一种方法是在 UoW 界面上公开您的存储库（我更喜欢前者）。无论哪种方式都可以更轻松地对每一层进行单元测试。然后，从服务层内对 UnitOfWork 进行一次 Save 调用，即可在所有存储库中保留所有更改。
这是MSDN 上的一篇不错的文章，从单元测试的角度审视了 UoW但也涵盖存储库。在它引用来自 MVC 控制器的存储库的地方，您将拥有另一个中间服务层。
You are correct in your assumptions on the layering. Your EF Context is the Unit Of Work. Generally you'll abstract this away through an interface and then constructor inject into each Repository for CRUD operations. Another approach is to expose your Repositories on the UoW interface (I prefer the former). Either way allows for easier unit testing of each layer. A single call to Save on the UnitOfWork from within the service layer will then persist all changes across all Repositories.
Here's a nice article on MSDN that looks at UoW from a unit testing perspective but covers repositories also. Where it references Repositories from the MVC Controller you'll have another intermediary service layer.
我开始将工作单元隐藏在较低层的某个位置，但这是错误的方法。经过一些经验后，我的观点是：
原因是提到的层定义了什么是“业务事务”=什么是当前工作单元。只有这一层知道何时要将更改提交到数据存储。这样做可以实现服务组合（代码重用）。我此处讨论了类似的问题此处。
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:
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.
Sam、
Julie Lerman 在 DNR 电视上做了一个很好的截屏视频，谈论这个，那里也是 Channel 9 上的另一个截屏，围绕 EF 此处。
与这些相关的一般事情是在 Nhibernate 中创建工作单元的抽象，在 EF 中将是您的上下文，并将该会话或上下文传递到您的存储库中，作为测试的一部分，您可以伪造连接以使用字典列表。
希望这些有帮助。
伊恩
Sam,
Julie Lerman did a good screencast on DNR tv, talking about this, there is also another screen cast on Channel 9, around creating and testing repositories just EF here.
The general thing abut these is create the abstraction of the Unit of Work in Nhibernate it would be Session, in EF would be you context and passing that session or context into your repositories, as part of you test you can fake the connections to use a list of dictinary.
Hope these help.
Iain