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