ASP.net MVC 中哪种方法更好？答案

【问题标题】：Which is better approach in ASP.net MVC?ASP.net MVC 中哪种方法更好？
【发布时间】：2011-12-12 13:24:16
【问题描述】：

第一种方法

   /\
  /  \
V/    \ C <=WCF=> {Business Layer (with business logic) <=> ORM <=> Database}
/      \
--------
    M

第二种方法

   /\
  /  \
V/    \ M <=WCF=> {Business Layer (with business logic) <=> ORM <=> Database}
/      \
--------
    C

主要区别： - 在第一种方法中，业务对象将有 2 个版本。一个加载了业务层内的属性，另一个加载了几个视图特定属性的哑版本，由控制器填充。在第二种方法中，将有一个具有所有属性的类。 - 第一种方法似乎与表示层更加分离

在这两种方法中，控制器都是起点。就我从不同人那里收到的观点而言，两者都是有效的方法，可以根据开发偏好进行切换。
请分享想法。

【问题讨论】：

看起来你的模型层在这两种情况下都没有做任何事情，更像是“查看模型”。我同意 alex - 你的模型应该包含你的业务逻辑。模型应包含与业务领域相关的信息和行为。
两者有什么区别？ C 正在听 BL 或 M 正在听 BL。我建议创建包装 V & M 的 ViewModel (VM)。
MVC 是一个表示方面。如果我使用第一个选项，我可以在 MVC 或 Silverlight MVVM 或其他模式之间轻松切换，因为我的业务逻辑和核心域实体是完整的。模型在第二种方法中并不完全愚蠢。控制器只会实例化模型，而模型的构造器实际上会与业务层对话以获取用于填充自身的数据。
MVC 中的模型是您的 WCF 服务（或任何其他数据源）。这是事实。没有任何变化。您的第二种方法不是 MVC。
有趣的是，只有我能找到仍然喜欢方法 B 的人（正如他们所说的控制器应该是愚蠢的）来自 JAVA 世界......

【解决方案1】：

我们在 asp.net mvc 应用程序中使用下一种方法：

视图

您可以从Professional ASP.NET Design Patterns获取有关此方法的更多详细信息

【讨论】：

我知道 jgauffin 也喜欢这种方法。只是为了最后的澄清，例如，有一个 WCF 层，所有逻辑都集成并通过 ORM 与数据库交互，所以它将被视为控制器将用于填充 ViewModel 的模型？谢谢

【解决方案2】：

第一个。 ViewModel（您在三元组中称为“M”）不应该知道 View 或业务层中的任何内容。

真正的MVC定义：

微软添加了 ViewModel 以使分离更加清晰。对于初学者，视图不应依赖于您的域模型。它不应该包含逻辑。

【讨论】：

视图模型不值得麻烦，除非您正在处理多个“视图”层，因为所有工作都可以（并且应该）由模型本身完成。另一方面，对于多个“视图”层，您需要它们，否则您将无法为任务提出正确的“模型”。最终，无论如何，任何可行且易于维护/更新的作品都是可行的。
如果这对你有用，那就太好了。从那以后，这对我不起作用，我倾向于在我的观点中添加逻辑。如果属性为空，则主要是一些小事情，例如显示默认文本。所有这些小的更改都会在使用模型的所有视图中重复，最终变成难以维护的大混乱。通过使用视图模型，我将这些更改保存在一个地方，并且我的视图很干净。
我也喜欢拥有单独的视图模型的想法。但是，将域对象转换为控制器层中的视图模型对象对性能有何影响？
我可以向您保证，我可以在您的代码中找到另外十个重要的性能问题。这些对象成本是最低的。
哈哈。就像上面的好文章一样，你有任何关于 ASP.NET MVC 的性能文章吗？但是你让我很好奇这 10 个问题可能是什么:)

【解决方案3】：

imho 业务逻辑属于模型。控制器不应该知道也不应该关心您为什么要在视图中显示某些内容。

事实上，我认为这是最适合这里的工作的问题，而不是绝对的“最佳”。

【讨论】：