对我而言，这似乎没有多大意义，但在阅读以下信息之后：
http://bradwilson.typepad.com/blog/2010/01/input-validation-vs-model-validation-in-aspnet-mvc.html
http://blog.stevensanderson.com/2010/02/19/partial-validation-in-aspnet-mvc-2/#comment-35397（特别是一些评论）
Asp.Net MVC背后的想法似乎是你在模型和视图之间有一对一的关系。这似乎违反了DRY原则和其他一些标准编程实践。
例如，假设您有一个用户帐户模型，并且有两个可用于编辑它的视图 - 一个用于用户自己编辑它，另一个用于网站管理员进行编辑。管理员可以访问内部的其他字段，但是用户无法查看/编辑它。根据模型绑定功能和上面引用的帖子中描述的信念，我需要创建两个单独的用户模型，每个页面一个，唯一的区别是附加字段。这只是一个简单的例子，我有一些我已经看到它可能意味着完全相同的对象的5或6个不同的模型，每个视图之间只有几个不同的字段。这对我来说没有任何意义。
答案 0 :(得分：2)
我没有阅读你提到的帖子，但是为一些视图设置一个模型没有任何问题。
我只有一个UserModel并在所有视图中使用它，即使有一些字段未使用。
如果事情变得有点复杂但用户仍然有很多共同点，你可以使用聚合为usermodel（User.Address）或使用接口（用户有字段street，city和implements IAddress）。
这两种方法各有利弊 - 在大多数情况下使用聚合。
修改
阅读帖子后，我看到他们处理验证。这是一个不同的故事。 如果要使用DataAnotations，则必须在验证不同时使用不同的类。我不使用DataAnnotations - 所以我猜你的课程设计可能会有所不同。
答案 1 :(得分：1)
如果您正在使用注释，我会强烈考虑一个“模型”和多个“视图模型”。我们使用viewmodel方法在我们当前的应用程序上获得了收益，因为我们的基本模型需要以几种不同的视图显示。
答案 2 :(得分：0)
没有官方要求在ASP.NET MVC中每个模型只有一个视图。在许多情况下会导致代码重复。
我个人喜欢拆分模型视图依赖项，即每个模型一个视图。它归结为这样一个事实：你永远不会知道，例如，一些非常相似的模型 - 视图对将来会如何发展。如果它们是分开的，您只需在一个中引入更改，您不必“修复”依赖于此模型的其他视图，或者更糟糕的是，需要额外的工作来同时为它们创建自己的模型。 / p>
答案 3 :(得分：-1)
TL; DR：制作多个视图模型。它们既便宜又灵活。
“这似乎违反了DRY原则和其他一些标准编程实践。”
[需要引用]？
MVC不会改变任何语言或模式中需要为每个单独的屏幕制作视图模型定义的事实。无论是通过属性，通过XML，还是通过切换Web表单控件，等等。
DRY委托人通常与重复业务逻辑有关。在CRUD屏幕部分重复FirstName属性确实不是什么大问题。甚至5-6次，那是什么？ 40秒？
如果您将视图模型误认为是面向对象的类而不是homoiconisticish screen表示，那么您将面临填充它们的风险，这将是各种继承和/或业务逻辑。
当您制作愚蠢的视图定义时，您的编程并不真正。这项工作可以在Access GUI中轻松完成，也可以用XML定义。您的屏幕视图模型使用C＃这一事实可以让您更轻松地填充数据并将其发布并使用WCF和Automapper等工具。