我一直在研究 ASP.net MVC 一段时间。似乎大多数博客和帖子都表明“最佳实践”是通过实现存储库模式来抽象出实体框架。似乎推荐的做法是使用特定于视图的模型，而不是直接使用 EF 域实体。
这是有道理的，因为您可以在存储库中实现一个透明的缓存层，您的 MVC 应用程序不需要了解有关实体框架的任何信息，并且特定于视图的 POCO 模型没有附加所有 EF 方法和属性给他们（这往往会弄乱 XML 和 JSON 序列化）。
但如果这是人们“应该”开发的方式，为什么 Visual Studio 中的所有控制器/视图向导和工具都直接专注于实体框架？为什么http://www.asp.net/mvc上的所有 Microsoft 示例似乎都直接与框架和域实体一起工作，而不是创建具有缓存和使用视图特定模型的存储库？
另外，如果我应该使用特定于视图的模型，我是否将域实体映射到控制器中的那些模型上？如果我只需要某些字段，将对象图返回给控制器不是效率低下吗？或者我应该在我的存储库上创建特定于视图模型的方法？
为什么http://www.asp.net/mvc上的所有 Microsoft 示例似乎都直接与框架和域实体一起工作，而不是创建具有缓存和使用视图特定模型的存储库？
不幸的是，我不能回答这个问题，因为我不是在创建这些向导的 Visual Studio 团队中工作的 Microsoft 员工，也不是在http://asp.net/mvc站点上发布内容。就我个人而言，我对 Visual Studio 中 99% 的向导都过敏，并且从未接触过它们。
另外，如果我应该使用特定于视图的模型，我是否将域实体映射到控制器中的那些模型上？
是的。或者，您可以使用AutoMapper来简化此过程并整理您的控制器操作。
如果我只需要某些字段，将对象图返回给控制器不是效率低下吗？
不，它是有效的。事实上，它甚至比映射到视图模型更快（在性能方面）。只是在大多数情况下，您的领域模型不适合您的视图要求。从那一刻起，噩梦将在您的视图中开始，这些视图将变成意大利面条式代码，以尝试适应这些领域模型——您的视图现在变得低效且不易维护。您将很快意识到域模型并不包含视图所需的所有必要信息。接下来会发生什么？你开始使用另一个我对它过敏的概念——ViewBag. 所以你以强类型模型的形式将某些东西传递给视图，以弱类型结构的形式将其他东西传递给视图，事情变得混乱。此外，采用域模型而不是视图模型的控制器操作容易受到大规模注入攻击，并且您可能会遇到验证等问题。
或者我应该在我的存储库上创建特定于视图模型的方法？
绝对不。存储库仅适用于域模型。它不知道什么是视图模型。
当然，所有这些都是我的 2 美分。如果这是更适合您并且您感觉更舒服的模式，则完全可以忽略它们并直接在您的视图中使用您的 EF 域模型。试图强加一种或另一种模式是不正确的。只需使用您认为适合您需求的那个。
与最佳实践一样，它们往往不会涵盖所有情况。使用存储库模式被认为是企业解决方案的最佳实践。但是，如果您只是将一个不需要大量维护的快速网站放在一起，那就太矫枉过正了。有些人会告诉您，您应该始终使用最佳实践，但实际上您通常只是想得到一些可行的方法。如果是这种情况，生成的方法既快速又简单。
此外，如果您正在学习 MVC，存储库模式是另一回事，我猜 MS 会按照他们帮助新手的方式设置它，因为他们知道更有经验的开发人员可能无论如何都希望以自己的方式进行操作。
只是预感：p