首先，这是我的MVC学习的第二周，我对使用MVC设计更好的网站结构感到非常好奇
在ASP.NET MVC框架中，强烈建议将大多数业务逻辑代码写入模型而不是控制器，我的问题是，它背后的好处是什么？操纵控制器中的数据不是很好吗？那会占用更多的资源和时间吗？
欢迎任何形式的想法。如果您有=]
，请将任何文章链接发送给我答案 0 :(得分：2)
@MystereMan只是部分正确。在真蓝色MVC模式中，是的，所有业务逻辑都属于模型。我不是在谈论ASP.NET MVC，而是实际的抽象MVC模式。
实际上，模型通常是数据库中表行的表示，因此将所有业务逻辑放在＆＃34;模型中是很多次，甚至不可能。我们倾向于提到一个主要数据库支持的模型＆＃34;在这个意义上作为一个＆＃34;实体＆＃34;。该实体是一个＆＃34;模型＆＃34;您的数据库状态（或更新时对该状态的更改）从这个意义上讲，它不适用于未在数据库层中表示或适用的其他逻辑。
这就是为什么大多数开发人员会添加一个名为＆＃34; view model＆＃34;的概念，这个概念借用了一种名为MVVVM（模型 - 视图 - 视图模型）的模式。这种模式是MVC的替代方案，但两者并不相互排斥。换句话说，它是可能的，甚至建议将两者的概念混合并匹配成一种混合模式。
在ASP.NET MVC中，这通常表现为添加了一个＆＃34;视图模型＆＃34;到现有的MVC结构。您的模型将成为数据库支持的实体，视图模型将包含上下文中视图所需的模型数据的子集以及仅与所述视图相关的任何其他数据或逻辑，该视图利用此视图模型呈现自身和控制器仍将所有事情联系在一起。
但基本效果是一样的。视图模型基本上承担了＆＃34;模型的作用。 MVC，是的，你的所有业务逻辑都应该放在这里。设计良好的视图将只有最少量的服务器端代码来呈现它; for循环，简单if语句等都可以，但计算不行。控制器的工作仅仅是返回响应，这意味着获取视图需要呈现的任何内容。它不应该知道您的数据，也不关心正在与哪些数据进行交互。它只是将它获取的任何内容传递给视图并发送响应。
答案 1 :(得分：1)
MVC的意思是关注点的分离 - 控制器不应该知道数据来自何处，或者它采用什么格式，或者需要应用什么逻辑来检索数据。
该模型的工作是向控制器提供数据;不多也不少。好处是关注点的分离 - 如果您将来需要更改业务逻辑，则只需在模型中将其更改为一个位置。
在资源和时间方面，我不知道如果在控制器中完成数据操作，程序的效率必然会降低。但它的设计可能很差，难以维护。
MVC wikipedia article是一个很好的起点。
答案 2 :(得分：0)
Idea不是资源利用率。但这个想法是曼斯菲尔德提到的“关注点分离”。
大多数人误解了将模型称为数据 - 原始数据。但这不正确。模型是数据的逻辑结构的基础。这意味着逻辑结构和过滤当前上下文的数据。因此，只有处理过的数据才会出现在您的模型中。
由于这种分离关注，您还可以对这三个部分进行独立的自动化测试。您可以完全独立于Controller测试模型，反之亦然。
答案 3 :(得分：0)
那么，你把业务逻辑放在哪里？我已经和它搏斗了一段时间，我根据应用程序的大小和复杂程度提出了不同的位置。
Tiny app：使用数据注释将业务逻辑放在模型上，并为注释无法实现的任何自定义规则实现IValidatableobject接口。
中型应用：构建服务层，您的服务对象充当您的域模型的网关，并可以验证任何业务规则。这是一个很好的资源：http://www.asp.net/mvc/tutorials/older-versions/models-%28data%29/validating-with-a-service-layer-cs
大应用程序：服务层现在是业务层的外观，其中验证在复杂的消息传递框架和工作流中进行。
我想指出，我喜欢在我的模型/视图模型上放置验证规则，而不管应用程序的大小。我相信他们应该知道他们何时处于错误状态，这与违反业务规则的情况不同。