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

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

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

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

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

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

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

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

为什么不引入一个服务层呢?这样你的控制器就会精简，可读性更强，所有的控制器功能都是纯粹的动作。您可以根据需要在服务层中分解业务逻辑。代码可重用性很高。对模型和存储库没有影响。

首先: 我相信您混淆了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.

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

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

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

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