我一直在读，MVC模式中最大的层应该是模型。我还听说我们应该避免在控制器层上放置逻辑。但是，随着我的ASP.Net MVC 5应用程序越来越大，我看到我的视图很重，控制器很重，而且......非常小的模型（它们只不过是对我的SQL表的引用）。
是的，我承认，我永远无法在我的模型上设置任何逻辑。
我喜欢MVC模式，而且我的网站运作良好，但我一直认为我肯定做得不对......
您能告诉我一些关于如何正确编写MVC代码的有用链接吗？ Rick Anderson的（微软）MVC 5教程很好，但他的模型确实非常小......
答案 0 :(得分：3)
在我的应用程序中，我在域模型中尽可能多地使用逻辑。最重要的是，有一个应用程序层，它与数据库和域模型交互以执行特定于应用程序的操作。控制器操作具有尽可能少的代码，只需调用应用程序层中的方法。
此外，我通常为每个视图都有一个视图模型。任何使你的观点“沉重”的逻辑就会消失。
我尝试在域模型中尽可能多地使用逻辑的一个主要原因是使单元测试更容易。应用程序层中的逻辑通常涉及数据库，您需要模拟该数据库才能进行测试。将逻辑移动到域模型可以使测试更容易，并使您的代码更具可重用性。
这是一个非常复杂的问题。如果您有兴趣，我会对问题进行深入blog post。
This answer也非常接近我的建议。
答案 1 :(得分：1)
在模型和控制器之间使用额外的层（例如repositories作为数据访问层）。 我强烈建议使用ViewModels - 它们使代码更有条理。
答案 2 :(得分：1)
你错过了一个服务/业务层，它应该通过“依赖注入”注入你的控制器。这些服务完成了所有繁重的工作。
拥有没有任何方法或操作的模型是一件好事。你只是存储这个信息。他们基本上只是得到;组;数据
答案 3 :(得分：1)
您应该创建一些纯粹执行业务逻辑的类，并为MVC视图发出ViewModel。控制器应响应操作，操作方法将模型的责任委托给此业务类。
答案 4 :(得分：0)
经过对此问题的一些研究，并考虑到其中的一些答案和评论，我意识到中型MVC项目不能完全依赖于3层模型。随着控制器操作变得更大，开发人员开始感觉需要创建第4层：服务层。就像Gunnar Peipman在下面的博客文章中正确建议的那样，“Controller与服务层进行通信并获取有关访问代码如何声明成功的信息”：http://weblogs.asp.net/gunnarpeipman/archive/2011/06/20/asp-net-mvc-moving-code-from-controller-action-to-service-layer.aspx