ASP.NET MVC 模型模式：什么效果最好？答案

【问题标题】：ASP.NET MVC Model Patterns: What works best?ASP.NET MVC 模型模式：什么效果最好？
【发布时间】：2010-11-04 17:32:25
【问题描述】：

我在 ASP.NET MVC 中完成了几个项目，其中有一个主题我在任何地方都没有真正看到过。我想听听其他人对此的看法。

设计模型有哪些最佳实践？过去我采用了两种方法：模型应该代表不同的实体，还是应该具有特定于域的（特定于子域？特定于视图？）模型？真正的区别在于表示不同实体的模型用于多个视图中，因为特定领域的模型与特定视图相关联。

考虑以下情况：我的应用程序中有一个用户实体。我应该在 Register 视图、Show 视图、Index 视图等中使用单个 UserModel，还是更喜欢使用 RegisterUserModel、ShowUserModel、ListUserModel 等？

我以前使用过这两种模式。领域特定模型的优势在于，通过属性应用的任何验证逻辑在视图之间都可能不同。不利的一面是你违反了 DRY 并且你的模型变得非常多毛——即使你将它们分成命名空间。相反，使用单一模型到实体模式会导致验证数据过于通用（通常与错误消息有关），但您有一个很好、紧密的模型层，并且模型和实体之间的转换要容易得多（代码更少）。

SO 更喜欢哪种方法？或者有没有我什至没有考虑过的方法？

【问题讨论】：

我相信你会从喜欢这两种方式的人那里得到答案。这是相当主观的。
讨论不是很有趣吗？

标签： c# asp.net-mvc design-patterns

【解决方案1】：

我喜欢创建我的数据模型，然后根据需要创建特定的视图模型。

The Case for ViewModel

The ViewModel Pattern

【讨论】：

【解决方案2】：

当我想到域模型时，我也会想到业务逻辑。我尝试在 MVC 中保留 M 来指代有助于应用程序呈现方面的模型，而不是代表我的真实世界对象的实体（域对象）。

【讨论】：

我也订阅了这一点，我认为很多其他框架都忽略了这一点——即 RoR。

【解决方案3】：

模型和视图应该是一对。构建巨大的模型类和巨大的视图不是一个好主意。在我看来，在您的视图模型中，您应该只代表业务逻辑中需要的部分。例如。当您创建注册表单时，让您的模型和视图尽可能简单 - 创建 RegisterUserModel.cs 和 RegisterUserView.aspx。不要在那里传递整个用户对象。轻松一点，不要违反单一职责原则。

【讨论】：