在模型层 (MVC) 上实现应用程序逻辑答案

【问题标题】：Implementing application logic on model layer (MVC)在模型层 (MVC) 上实现应用程序逻辑
【发布时间】：2014-04-13 14:25:46
【问题描述】：

我一直在读到，MVC 模式中最大的层应该是模型。我还听说我们应该避免将逻辑放在控制器层上。然而，随着我的 ASP.Net MVC 5 应用程序变得越来越大，我看到我得到了繁重的视图、繁重的控制器和......非常小的模型（它们只不过是对我的 SQL 表的引用）。

是的，我承认，我永远无法将任何逻辑放在我的模型上。

我喜欢 MVC 模式，我的网站运行良好，但我一直认为我做的事情肯定不对...

你能告诉我一些关于如何正确编写 MVC 代码的有用链接吗？ Rick Anderson (Microsoft) 的 MVC 5 教程很好，但再一次，他的模型确实非常小......

【问题讨论】：

您的视图/控制器的重量如何？你做很多手术吗？访问控制器中的数据？在视图端排序/过滤？？？
stackoverflow.com/questions/4565681/…stackoverflow.com/questions/18563229/…
@user1010863 我试图基本上说出那个答案所说的但是，我自己不能说这个答案更好

标签： asp.net-mvc model-view-controller asp.net-mvc-5

【解决方案1】：

在模型和控制器之间使用额外的层（例如 repositories 作为数据访问层）。我强烈推荐使用ViewModels——它们使代码更有条理。

【讨论】：

【解决方案2】：

您缺少应该通过“依赖注入”注入控制器的服务/业务层。这些服务完成了所有繁重的工作。

拥有没有任何方法或操作的模型是一件好事。无论如何，您只是存储此信息。他们基本上只是得到；放;数据。

【讨论】：

【解决方案3】：

您应该创建一些纯粹执行业务逻辑的类并为 MVC 视图发出 ViewModel。控制器应响应操作，操作方法将获取模型的责任委托给此业务类。

【讨论】：

【解决方案4】：

在我的应用程序中，我将尽可能多的逻辑放在域模型中。除此之外，还有一个应用层，它与数据库和域模型交互以执行特定于应用程序的操作。控制器动作的代码尽可能少，只调用应用层中的方法。

此外，我通常为每个视图创建一个视图模型。任何让你的观点“沉重”的逻辑都会去那里。

我尝试在域模型中加入尽可能多的逻辑的主要原因之一是使单元测试更容易。应用层中的逻辑通常涉及数据库，您需要对其进行模拟以进行测试。将逻辑移至域模型使测试更容易，并使您的代码更具可重用性。

这是一个相当复杂的问题。如果您对此问题感兴趣，我有一个深入的blog post。

This answer 也非常接近我的建议。

【讨论】：

出于多种原因，我绝对赞成使用视图模型。通常，视图需要的不仅仅是单个域模型所提供的。视图模型允许您为视图提供所有必要的数据，而无需在 ViewBag 中扔东西。视图模型还为您提供了一个放置逻辑和表达式的地方，这些逻辑和表达式本来可以在控制器操作中或直接在视图中完成。
您好 jdehlin，感谢您的回答和发布博客。我想听听您对 Sebin 帖子的看法。你同意他吗？让控制器和第三方类都将模型/视图模型发送到视图不是一种不好的做法吗？我的控制器正在将各自的模型发送到视图，但我对创建将 ViewModel 也发送到视图的第三方类犹豫不决。感谢您在 MVC 问题上的专业知识。我读到有些人将 MVC 视为实际上是 MVVC，我认为可能是这种情况。
并不是你同时发送模型和视图模型。如果需要，您的模型可以添加到视图模型中。或者，您可以使您的视图模型具有与您的模型相似的属性，并使用 AutoMapper 之类的东西将一个映射到另一个。或者您可以让您的视图模型从域模型继承并覆盖/扩展它。这种灵活性是视图模型的好处。您根据具体情况为视图设计它，而不是试图塑造您的域模型以适应您的视图。我认为这就是 Sebin 发出视图模型的意思。
我同意 Chris Pratt 在链接回复中所说的大部分内容。不过，我不同意持久性属于域模型。我认为持久性属于应用层。视图模型不仅仅代表处于不同状态的域模型（尽管可以这样）。例如，假设我们有一个显示来自三个不同领域模型的数据的视图。我们可以创建一个视图模型，它具有三个属性，一个用于我们视图中需要的每个域模型。
这个问题没有真正的“正确”答案。你能做的最好的事情就是学习和实践人们为什么做这些事情背后的基本原则。 SOLID原则等等等等。

【解决方案5】：

在对这个问题进行一些研究后，并考虑到其中一些答案和 cmets，我意识到一个中型 MVC 项目不能完全依赖 3 层模型。随着控制器动作变大，开发人员开始感到需要创建第四层：服务层。就像 Gunnar Peipman 在以下博客文章中正确建议的那样，“控制器与服务层通信并获取有关访问代码声明如何成功的信息”：http://weblogs.asp.net/gunnarpeipman/archive/2011/06/20/asp-net-mvc-moving-code-from-controller-action-to-service-layer.aspx

【讨论】：