具有存储库和工作模式单元的MVC 4

Question

我知道在mvc中，在ASP.net MVC项目中使用仓库模式和工作类单元作为设计模式是很好的(业务逻辑在服务层)。

我的问题是，我是Microsoft.can引入的MVC4的新手，我也在MVC4环境中应用了上面提到的模式(存储库和工作单元)，这是在设计模式中开始我的项目的好方法吗？

在MVC中，我需要满足大型MVC项目的另一种类型的模式。

有没有人知道MVC4，请评论一下，非常感谢。

Answer 1

“在mvc中，使用存储库模式和工作类单元是很好的”-这是非常值得怀疑的，而像“被认为是当今使用的最好的模式之一”这样的说法是完全错误的:模式只有在某些上下文中才是好的或坏的，如果没有它，你就不能真正判断它们是不是好的选择。

从“我应该使用哪些模式”这个问题开始，而不首先考虑您需要编写的应用程序的细节，这是创建过度设计的应用程序的必经之路。

存储库和UoW已经被Domain driven design普及了，如果你沿着这条路走下去，它们是很有意义的。DDD对于某些应用程序来说是很好的方法，但我认为这并不是大多数应用程序。许多web应用程序只是CRUD应用程序，它们不能从DDD或包装对存储库中实体的每次访问中受益-例如，在这里选择微ORM通常是一种更明智的方法。

如果你仍然确信你的应用程序真的需要这样的方法，而不是自己实现所有这些东西，我建议使用像NHibernate这样的框架，因为你需要的不仅仅是UoW和repo -它们将需要身份映射实现，等等。NHibernate提供了很多东西(例如，它的Session类型实际上是UoW的一个很好的实现，还有更多)，并且涵盖了许多细节，这些细节只有在你进入实现自己的版本的细节之后才会发现是必要的。实体框架在这里可能也是一个很好的选择，尽管它不是我的最爱。

当然，编写自己的代码是扩展知识的一种很好的方式，但是如果您的产品应用程序需要这样做，那么选择一个现有的实现将会节省大量的时间、金钱和麻烦。

Answer 2

仅仅因为Repository模式在每个教程中都会出现，并不意味着它是解决MVC世界中问题的事实上的标准。

首先你需要了解你的应用程序的复杂性，一个仓库可能会给你的application.BTW增加不必要的复杂性你还没有提到你将如何与你计划使用的任何对象关系管理工具(Nhibernate，实体框架)对话，然后你已经在place.Why中有了一个很好的抽象你还需要更多的抽象级别。

关于是否使用存储库patterns.Here有很多争论，这是一些非常好的解释

Do we need Repository ?

Life without repositories - Ayende

所有著名的ORM工具都是使用您提到的模式(工作单元和存储库)实现的。

Answer 3

看一看ASP.NET MVC教程上的Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application，这应该足以让你朝着正确的方向前进。