在MVC3中，我应该有单独的“编辑”模型和“显示”模型吗？
使用MVC3，我是否应该设计我的视图模型，使其有一个绑定到视图(DisplayModel)，另一个回发到控制器(EditModel)？
为了澄清，我并不是在问数据模型和视图模型--我知道将视图/控制器绑定到数据/域模型是不好的。
我也不是在问在两个单独的视图之间共享一个模型，一个视图用于显示数据，另一个视图用于编辑数据。
相反，我问的是一个用于编辑数据的视图，以及绑定到视图的模型和绑定到控制器操作的模型。
换句话说，如果这是我的观点：
@model MyApp.Models.CustomerModel我的控制器操作应该是这样的：
public ActionResult Index(CustomerModel model)或者：
public ActionResult Index(CustomerEditModel model)在某一点上，我们做的是后者(分开)。但最近，我们开始做前者(共享)。
此更改的原因是：
- 与MVC3非侵入性验证，如果我在我的模型上使用DataAnnotations进行验证，这在两个模型中都是需要的，如果它们是分开的(在显示模型上映射客户端验证，在服务器端应用程序成熟的编辑模型上，我们意识到我们的显示和编辑模型95%相同，除了视图模型中的选择列表。我们现在已经将它们移到了一个shared class中，并且现在正在通过视图传递它们。
但我看到其他一些讨论指出，让视图/控制器共享模型不是一个好主意，而且it violates分离了关注点。
有人能帮我理解一下这两种方法的权衡吗？
回答 5
Stack Overflow用户
发布于 2011-11-11 23:24:04
我已经看到了非常好的支持和反对的论据，这只是取决于什么最适合你的应用程序。没有一种适合所有人的方法可以应用！
如果你还没有读过，Jimmy Bogard写了一篇关于他的团队如何做MVC here的非常好的文章，其中涵盖了这个主题。
Stack Overflow用户
发布于 2012-08-10 21:36:44
我同意rich.okelly's answer的观点，没有正确的方法。
不过，我对使用一个模型有几个顾虑。
当视图需要显示可选择的对象列表时，总是使用一个模型而不具有不需要的属性，这将是非常重要的。模型需要有一个对象列表和一个属性来接受用户选择的POSTed值。这些不需要的属性会增加少量的代码杂乱和开销。(解决这个问题的一种方法是让模型只包含选定的ID，并使用HTML助手来构建列表。)
另一个问题更多地与安全有关。一种常见的情况是以应该被认为是只读的形式显示信息。在ViewModel和EditModel的情况下，EditModel将只包含预期为POSTed的属性，而ViewModel将包含所有属性。例如，如果一个表单显示了用户的工资，用户将能够发布一个“工资”，并通过MVC自动将其绑定到ViewModel的工资属性。在这一点上，必须执行以确保它不会最终进入数据库。它可以是if/else逻辑、绑定属性、Automapper逻辑或其他什么，但重点是它是一个可以忽略的步骤。在考虑应用程序的生命周期时，我喜欢EditModel随着时间的推移而显性。
这些问题并不意味着两个模型是好的，一个模型是不好的，但在选择设计时应该考虑它们。
Stack Overflow用户
发布于 2011-11-11 23:14:35
如果显示和编辑视图模型的属性相同，我认为没有理由使用不同的类。
https://stackoverflow.com/questions/8095923
复制相似问题