我知道在 mvc 中最好使用存储库模式和工作单元类作为 ASP.net MVC 项目中的设计模式。（服务层中的业务逻辑。）
我的问题是，我是 Microsoft 引入的 MVC 4 的新手。我是否也可以在 MVC 4 环境中应用上述模式（存储库和工作单元），以该设计模式开始我的项目是否是好方法。
在 MVC 中，大型 MVC 项目是否需要满足另一种类型的模式。
有没有人知道MVC 4的请评论一下，非常感谢。
【问题讨论】：
标签： c# asp.net-mvc design-patterns asp.net-mvc-4
“在 mvc 中使用存储库模式和工作单元类是很好的”——这是非常值得怀疑的，而说“被认为是今天使用的最佳模式之一”之类的话是完全错误的：模式只有好或坏在某些情况下，您无法真正判断它们是否是好的选择。
从“我应该使用哪些模式”这个问题开始，而不首先考虑您需要编写的应用程序的具体细节，这是创建过度设计应用程序的可靠方法。
Repository 和 UoW 已由 Domain driven design 推广，如果您沿着这条路走下去，它们会很有意义。 DDD 对于某些应用程序来说是极好的方法，但我认为这不是大多数应用程序。许多 Web 应用程序只是 CRUD 应用程序，它们不能从 DDD 中受益，也不会将对实体的每次访问都包装在存储库中——例如在这里选择微 ORM 通常是一种更明智的方法。
如果您仍然确定您的应用确实需要这种方法，而不是自己实现所有这些东西，我建议使用像 NHibernate 这样的框架，因为您需要的不仅仅是 UoW 和 repo - 它们需要身份地图实现等。NHibernate 提供了很多开箱即用的东西（例如，它的Session 类型实际上是 UoW 的出色实现以及更多），并涵盖了许多细节，您只有在进入后才会发现必要性实现您自己的版本的详细信息。实体框架在这里也可能是一个不错的选择，尽管它不是我最喜欢的。
当然，编写自己的代码是扩展知识的好方法，但如果您需要将其用于生产应用程序，则选择现有实现将节省大量时间、金钱和麻烦。
【讨论】：
仅仅因为存储库模式出现在每个教程中，并不意味着它是解决 MVC 世界中问题的事实标准。
首先，您需要了解应用程序的复杂性。存储库可能会给您的应用程序增加不必要的复杂性。顺便说一句，您还没有提到您将如何与数据库通信。如果您计划使用任何 ORM像（Nhibernate，Entity framework）这样的工具，那么你已经有了一个很好的抽象。为什么你还需要一个抽象级别。
关于是否使用存储库模式存在很多争论。这里有一些非常好的解释
Life without repositories - Ayende
所有著名的 ORM 工具都使用您提到的模式（工作单元和存储库）实现。
【讨论】：
Dan Whalin & John Papa 背景。他们是Microsoft MVP。 Scott Guthrie（在他们的会议期间）也推荐它。
查看 ASP.NET MVC 教程中的 Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application，这应该足以让您朝着正确的方向前进。
【讨论】：