业务规则在模型中。

假设您正在为邮件列表显示电子邮件。用户单击其中一封电子邮件旁边的“删除”按钮，控制器通知模型删除条目N，然后通知视图模型已更改。

也许管理员的电子邮件永远不应该从列表中删除。这是一个业务规则，该知识属于模型。视图最终可能以某种方式表示该规则——也许模型公开了一个“IsDeletable”属性，该属性是业务规则的一个功能，因此视图中的删除按钮对于某些条目是禁用的——但视图中不包含规则本身。

模型是数据的最终把关人。您应该能够在不接触UI的情况下测试业务逻辑。

正如几个答案所指出的，我相信人们对多层架构和MVC架构有一些误解。

多层架构包括将你的应用程序分解成几层(例如，表示、业务逻辑、数据访问)

MVC是应用程序表示层的一种体系结构样式。对于重要的应用程序，业务逻辑/业务规则/数据访问不应该直接放在模型、视图或控制器中。这样做会将业务逻辑放在表示层，从而降低代码的重用性和可维护性。

该模型是放置业务逻辑的一个非常合理的选择，但更好/更可维护的方法是将表示层与业务逻辑层分离，并创建一个业务逻辑层，并在需要时从模型中调用业务逻辑层。业务逻辑层将依次调用数据访问层。

我想指出的是，在一个MVC组件中发现混合了业务逻辑和数据访问的代码并不少见，特别是在应用程序没有使用多层架构的情况下。然而，在大多数企业应用程序中，您通常会在表示层中发现带有MVC体系结构的多层体系结构。

这是一个已回答的问题，但我将给出我的“一分钱”:

业务规则属于模型。 “模型”总是由(逻辑上或物理上分离的):

表示模型——一组非常适合在视图中使用的类(它针对特定的UI/表示进行定制)， 域模型——模型中与ui无关的部分，以及 存储库——“模型”的存储感知部分。

业务规则存在于领域模型中，以适合表示的形式公开给“表示”模型，有时在“数据层”中复制(或强制执行)。

Model =用于CRUD数据库操作的代码。

Controller =响应用户操作，并根据特定于组织的业务规则将用户的数据检索或删除/更新请求传递给模型。这些业务规则可以在助手类中实现，如果不是太复杂的话，也可以直接在控制器操作中实现。控制器最后要求视图更新自己，以便以新显示的形式给用户反馈，或者像'updated, thanks'之类的消息，

View =基于对模型的查询生成的UI。

关于业务规则应该放在哪里，没有硬性规定。在一些设计中，它们进入模型，而在另一些设计中，它们包含在控制器中。但我认为最好还是把它们放在控制器里。让模型只关心数据库连通性。

将业务层放在MVC项目的模型中是没有意义的。

假如你的老板决定把演示层换成别的东西，你就完蛋了!业务层应该是一个单独的程序集。Model包含来自业务层的数据，这些数据传递给视图进行显示。然后在post中，例如，模型绑定到驻留在业务层的Person类，并调用PersonBusiness.SavePerson(p);其中p是Person类。以下是我所做的(BusinessError类没有，但也会在BusinessLayer中):

首先: 我相信您混淆了MVC模式和基于n层的设计原则。 使用MVC方法并不意味着不应该对应用程序进行分层。 如果您将MVC看作是表示层的扩展，这可能会有所帮助。 如果你把非表示代码放在MVC模式中，你可能很快就会得到一个复杂的设计。 因此，我建议您将业务逻辑放到单独的业务层中。

看看这个:维基百科上关于多层架构的文章 它说:

今天，MVC和类似的模型-视图-表示器(MVP)都是关注点分离设计模式，专门应用于大型系统的表示层。

Anyway ... when talking about an enterprise web application the calls from the UI to the business logic layer should be placed inside the (presentation) controller. That is because the controller actually handles the calls to a specific resource, queries the data by making calls to the business logic and links the data (model) to the appropriate view. Mud told you that the business rules go into the model. That is also true, but he mixed up the (presentation) model (the 'M' in MVC) and the data layer model of a tier-based application design. So it is valid to place your database related business rules in the model (data layer) of your application. But you should not place them in the model of your MVC-structured presentation layer as this only applies to a specific UI. This technique is independent of whether you use a domain driven design or a transaction script based approach. Let me visualize that for you:

表示层:模型-视图-控制器

业务层:领域逻辑——应用程序逻辑

数据层:数据存储库-数据访问层

The model that you see above means that you have an application that uses MVC, DDD and a database-independed data layer. This is a common approach to design a larger enterprise web application. But you can also shrink it down to use a simple non-DDD business layer (a business layer without domain logic) and a simple data layer that writes directly to a specific database. You could even drop the whole data-layer and access the database directly from the business layer, though I do not recommend it.

[Note:] You should also be aware of the fact that nowadays there is more than just one "model" in an application. Commonly, each layer of an application has it's own model. The model of the presentation layer is view specific but often independent of the used controls. The business layer can also have a model, called the "domain-model". This is typically the case when you decide to take a domain-driven approach. This "domain-model" contains of data as well as business logic (the main logic of your program) and is usually independent of the presentation layer. The presentation layer usually calls the business layer on a certain "event" (button pressed etc.) to read data from or write data to the data layer. The data layer might also have it's own model, which is typically database related. It often contains a set of entity classes as well as data-access-objects (DAOs).

问题是:这如何适合MVC概念?

Answer -> It doesn't! Well - it kinda does, but not completely.This is because MVC is an approach that was developed in the late 1970's for the Smalltalk-80 programming language. At that time GUIs and personal computers were quite uncommon and the world wide web was not even invented! Most of today's programming languages and IDEs were developed in the 1990s. At that time computers and user interfaces were completely different from those in the 1970s. You should keep that in mind when you talk about MVC. Martin Fowler has written a very good article about MVC, MVP and today's GUIs.