Fist of all: I believe that you are mixing up the MVC pattern and n-tier-based design principles.
Using an MVC approach does not mean that you shouldn't layer your application. It might help if you see MVC more like an extension of the presentation layer.
If you put non-presentation code inside the MVC pattern you might very soon end up in a complicated design. Therefore I would suggest that you put your business logic into a separate business layer.
Today, MVC and similar model-view-presenter (MVP) are Separation of Concerns design patterns that apply exclusively to the presentation layer of a larger system.
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:
Presentation layer: Model - View - Controller
Business layer: Domain logic - Application logic
Data layer: Data repositories - Data access layer
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).
The question is: how does this fit into the MVC concept?
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.
Say you were displaying emails for a mailing list. The user clicks the "delete" button next to one of the emails, the controller notifies the model to delete entry N, then notifies the view the model has changed.
Perhaps the admin's email should never be removed from the list. That's a business rule, that knowledge belongs in the model. The view may ultimately represent this rule somehow -- perhaps the model exposes an "IsDeletable" property which is a function of the business rule, so that the delete button in the view is disabled for certain entries - but the rule itself isn't contained in the view.
The model is ultimately gatekeeper for your data. You should be able to test your business logic without touching the UI at all.
The term business logic is in my opinion not a precise definition. Evans talks in his book, Domain Driven Design, about two types of business logic:
Domain logic.
Application logic.
This separation is in my opinion a lot clearer. And with the realization that there are different types of business rules also comes the realization that they don't all necessarily go the same place.
Domain logic is logic that corresponds to the actual domain. So if you are creating an accounting application, then domain rules would be rules regarding accounts, postings, taxation, etc. In an agile software planning tool, the rules would be stuff like calculating release dates based on velocity and story points in the backlog, etc.
For both these types of application, CSV import/export could be relevant, but the rules of CSV import/export has nothing to do with the actual domain. This kind of logic is application logic.
Domain logic most certainly goes into the model layer. The model would also correspond to the domain layer in DDD.
Application logic however does not necessarily have to be placed in the model layer. That could be placed in the controllers directly, or you could create a separate application layer hosting those rules. What is most logical in this case would depend on the actual application.
A1: Business Logic goes to Model part in MVC. Role of Model is to contain data and business logic. Controller on the other hand is responsible to receive user input and decide what to do.
A2: A Business Rule is part of Business Logic. They have a has a relationship. Business Logic has Business Rules.
Take a look at Wikipedia entry for MVC. Go to Overview where it mentions the flow of MVC pattern.
As a couple of answers have pointed out, I believe there is some some misunderstanding of multi tier vs MVC architecture.
Multi tier architecture involves breaking your application into tiers/layers (e.g. presentation, business logic, data access)
MVC is an architectural style for the presentation layer of an application. For non trivial applications, business logic/business rules/data access should not be placed directly into Models, Views, or Controllers. To do so would be placing business logic in your presentation layer and thus reducing reuse and maintainability of your code.
The model is a very reasonable choice choice to place business logic, but a better/more maintainable approach is to separate your presentation layer from your business logic layer and create a business logic layer and simply call the business logic layer from your models when needed. The business logic layer will in turn call into the data access layer.
I would like to point out that it is not uncommon to find code that mixes business logic and data access in one of the MVC components, especially if the application was not architected using multiple tiers. However, in most enterprise applications, you will commonly find multi tier architectures with an MVC architecture in place within the presentation layer.
This is an answered question, but I'll give my "one cent":
Business rules belong in the model. The "model" always consists of (logically or physically separated):
presentation model - a set of classes that is well suited for use in the view (it's tailored toward specific UI/presentation),
domain model - the UI-independent portion of the model, and
repository - the storage-aware portion of the "model".
Business rules live in the domain model, are exposed in a presentation-suitable form to the "presentation" model and are sometimes duplicated (or also enforced) in the "data layer".
假设你的老板决定将表示层更改为其他内容，你就完蛋了！业务层应该是一个单独的组件。模型包含来自业务层并传递到视图以显示的数据。例如，在发布时，模型绑定到驻留在业务层中的 Person 类并调用 PersonBusiness.SavePerson(p);其中 p 是 Person 类。这就是我所做的（缺少 BusinessError 类，但也会进入 BusinessLayer）：
It does not make sense to put your business layer in the Model for an MVC project.
Say that your boss decides to change the presentation layer to something else, you would be screwed! The business layer should be a separate assembly. A Model contains the data that comes from the business layer that passes to the view to display. Then on post for example, the model binds to a Person class that resides in the business layer and calls PersonBusiness.SavePerson(p); where p is the Person class. Here's what I do (BusinessError class is missing but would go in the BusinessLayer too):
最后，请注意 MVC 因上下文而异。例如，在 Android 应用程序中，建议使用一些与基于 Web 的定义不同的替代定义（请参阅此 帖子< /a> 例如）。
Q2：
业务逻辑更通用，（如上面提到的“decyclone”）我们有以下关系：
业务规则⊂业务逻辑
Q1:
Business logics can be considered in two categories:
Domain logics like controls on an email address (uniqueness, constraints, etc.), obtaining the price of a product for invoice, or, calculating the shoppingCart's total price based of its product objects.
More broad and complicated workflows which are called business processes, like controlling the registration process for the student (which usually includes several steps and needs different checks and has more complicated constraints).
The first category goes into model and the second one belongs to controller. This is because the cases in the second category are broad application logics and putting them in the model may mix the model's abstraction (for example, it is not clear if we need to put those decisions in one model class or another, since they are related to both!).
See this answer for a specific distinction between model and controller, this link for very exact definitions and also this link for a nice Android example.
The point is that the notes mentioned by "Mud" and "Frank" above both can be true as well as "Pete"'s (business logic can be put in model, or controller, according to the type of business logic).
Finally, note that MVC differs from context to context. For example, in Android applications, some alternative definitions are suggested that differs from web-based ones (see this post for example).
Q2:
Business logic is more general and (as "decyclone" mentioned above) we have the following relation between them:
Why don't you introduce a service layer. then your controller will be lean and more readable, then your all controller functions will be pure actions. you can decompose business logic as you much as you need within service layer . code reusability is hight . no impact on models and repositories.
Controller = responds to user actions, and passes the user requests for data retrieval or delete/update to the model, subject to the business rules specific to an organization. These business rules could be implemented in helper classes, or if they are not too complex, just directly in the controller actions. The controller finally asks the view to update itself so as to give feedback to the user in the form of a new display, or a message like 'updated, thanks', etc.,
View = UI that is generated based on a query on the model.
There are no hard and fast rules regarding where business rules should go. In some designs they go into model, whereas in others they are included with the controller. But I think it is better to keep them with the controller. Let the model worry only about database connectivity.
发布评论
评论（10）
所有人的拳头：
我相信您混淆了 MVC 模式和基于 n 层的设计原则。
使用 MVC 方法并不意味着您不应该对应用程序进行分层。
如果您认为 MVC 更像是表示层的扩展，这可能会有所帮助。
如果将非表示代码放入 MVC 模式中，您可能很快就会陷入复杂的设计。
因此，我建议您将业务逻辑放入单独的业务层中。
看看这个：关于多层架构的维基百科文章
它说：
无论如何......在谈论企业 Web 应用程序时，从 UI 到业务逻辑层的调用应放置在（表示）控制器内。
这是因为控制器实际上处理对特定资源的调用，通过调用业务逻辑来查询数据并将数据（模型）链接到适当的视图。
Mud 告诉您业务规则已纳入模型中。
这也是事实，但他混淆了（表示）模型（MVC 中的“M”）和基于层的应用程序设计的数据层模型。
因此，将与数据库相关的业务规则放置在应用程序的模型（数据层）中是有效的。
但是您不应该将它们放置在 MVC 结构的表示层的模型中，因为这仅适用于特定的 UI。
该技术与您使用域驱动设计还是基于事务脚本的方法无关。
让我为您形象地展示一下：
表示层：模型 - 视图 - 控制器
业务层：域逻辑 - 应用程序逻辑
数据层：数据存储库 - 数据访问层
您在上面看到的模型意味着您有一个应用程序它使用 MVC、DDD 和独立于数据库的数据层。
这是设计大型企业 Web 应用程序的常用方法。
但您也可以将其缩小以使用简单的非 DDD 业务层（没有领域逻辑的业务层）和直接写入特定数据库的简单数据层。
您甚至可以删除整个数据层并直接从业务层访问数据库，但我不推荐这样做。
[笔记：]
您还应该意识到这样一个事实：现在应用程序中不止一个“模型”。
通常，应用程序的每一层都有自己的模型。
表示层的模型是特定于视图的，但通常独立于所使用的控件。
业务层也可以有一个模型，称为“域模型”。当您决定采用领域驱动方法时，通常会出现这种情况。
该“域模型”包含数据和业务逻辑（程序的主要逻辑），并且通常独立于表示层。
表示层通常在某个“事件”（按下按钮等）上调用业务层，以从数据层读取数据或向数据层写入数据。
数据层也可能有自己的模型，通常与数据库相关。它通常包含一组实体类以及数据访问对象 (DAO)。
问题是：这如何适应 MVC 概念？
答案->事实并非如此！
嗯 - 有点像，但不完全是。
这是因为 MVC 是 1970 年代末为 Smalltalk-80 编程语言开发的一种方法。那时 GUI 和个人电脑还很不常见，万维网甚至还没有发明！
当今大多数编程语言和 IDE 都是在 20 世纪 90 年代开发的。
当时的计算机和用户界面与 20 世纪 70 年代完全不同。
当您谈论 MVC 时，应该记住这一点。
Martin Fowler 写了一篇关于 MVC、MVP 和当今 GUI 的非常好的文章。
Fist of all:
I believe that you are mixing up the MVC pattern and n-tier-based design principles.
Using an MVC approach does not mean that you shouldn't layer your application.
It might help if you see MVC more like an extension of the presentation layer.
If you put non-presentation code inside the MVC pattern you might very soon end up in a complicated design.
Therefore I would suggest that you put your business logic into a separate business layer.
Just have a look at this: Wikipedia article about multitier architecture
It says:
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:
Presentation layer: Model - View - Controller
Business layer: Domain logic - Application logic
Data layer: Data repositories - Data access layer
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).
The question is: how does this fit into the MVC concept?
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.
业务规则包含在模型中。
假设您正在显示邮件列表的电子邮件。用户单击其中一封电子邮件旁边的“删除”按钮，控制器通知模型删除条目 N，然后通知视图模型已更改。
也许管理员的电子邮件永远不应该从列表中删除。这是一条业务规则，知识属于模型。视图最终可能以某种方式表示该规则 - 也许模型公开了一个“IsDeletable”属性，该属性是业务规则的函数，因此视图中的删除按钮对于某些条目被禁用 - 但是规则本身不包含在视图中。
该模型最终是数据的看门人。您应该能够在不接触 UI 的情况下测试您的业务逻辑。
Business rules go in the model.
Say you were displaying emails for a mailing list. The user clicks the "delete" button next to one of the emails, the controller notifies the model to delete entry N, then notifies the view the model has changed.
Perhaps the admin's email should never be removed from the list. That's a business rule, that knowledge belongs in the model. The view may ultimately represent this rule somehow -- perhaps the model exposes an "IsDeletable" property which is a function of the business rule, so that the delete button in the view is disabled for certain entries - but the rule itself isn't contained in the view.
The model is ultimately gatekeeper for your data. You should be able to test your business logic without touching the UI at all.
在我看来，业务逻辑这个术语并不是一个精确的定义。埃文斯在他的《领域驱动设计》一书中谈到了两种类型的业务逻辑：
我认为这种分离更加清晰。随着认识到存在不同类型的业务规则，我们也认识到它们不一定都去同一个地方。
领域逻辑是与实际领域相对应的逻辑。因此，如果您正在创建会计应用程序，那么域规则将是有关帐户、过帐、税收等的规则。在敏捷软件规划工具中，规则将类似于根据待办事项中的速度和故事点计算发布日期， 对于这两种类型的应用程序
，CSV导入/导出可能是相关的，但CSV导入/导出的规则与实际域无关。这种逻辑就是应用逻辑。
领域逻辑肯定会进入模型层。该模型也对应于 DDD 中的领域层。
然而，应用程序逻辑不一定必须放置在模型层中。它可以直接放置在控制器中，或者您可以创建一个单独的应用程序层来托管这些规则。在这种情况下什么最合乎逻辑取决于实际应用。
The term business logic is in my opinion not a precise definition. Evans talks in his book, Domain Driven Design, about two types of business logic:
This separation is in my opinion a lot clearer. And with the realization that there are different types of business rules also comes the realization that they don't all necessarily go the same place.
Domain logic is logic that corresponds to the actual domain. So if you are creating an accounting application, then domain rules would be rules regarding accounts, postings, taxation, etc. In an agile software planning tool, the rules would be stuff like calculating release dates based on velocity and story points in the backlog, etc.
For both these types of application, CSV import/export could be relevant, but the rules of CSV import/export has nothing to do with the actual domain. This kind of logic is application logic.
Domain logic most certainly goes into the model layer. The model would also correspond to the domain layer in DDD.
Application logic however does not necessarily have to be placed in the model layer. That could be placed in the controllers directly, or you could create a separate application layer hosting those rules. What is most logical in this case would depend on the actual application.
A1：业务逻辑转到
MVC中的Model部分。Model的作用是包含数据和业务逻辑。另一方面，控制器负责接收用户输入并决定做什么。A2：
业务规则是业务逻辑的一部分。他们有一个有关系。业务逻辑有业务规则。查看
MVC 维基百科条目。转到概述，其中提到了MVC模式的流程。另请参阅
业务逻辑的维基百科条目。提到业务逻辑由业务规则和工作流组成。A1: Business Logic goes to
Modelpart inMVC. Role ofModelis to contain data and business logic.Controlleron the other hand is responsible to receive user input and decide what to do.A2: A
Business Ruleis part ofBusiness Logic. They have ahas arelationship.Business LogichasBusiness Rules.Take a look at
Wikipedia entry for MVC. Go to Overview where it mentions the flow ofMVCpattern.Also look at
Wikipedia entry for Business Logic. It is mentioned thatBusiness Logicis comprised ofBusiness RulesandWorkflow.正如几个答案所指出的，我认为对多层架构与 MVC 架构存在一些误解。
多层架构涉及将应用程序分解为层/层（例如表示、业务逻辑、数据访问）。MVC
是应用程序表示层的架构风格。对于重要的应用程序，业务逻辑/业务规则/数据访问不应直接放入模型、视图或控制器中。为此，请将业务逻辑放置在表示层中，从而减少代码的重用和可维护性。
该模型是放置业务逻辑的非常合理的选择，但更好/更可维护的方法是将表示层与业务逻辑层分离并创建业务逻辑层，并在需要时简单地从模型中调用业务逻辑层。业务逻辑层将依次调用数据访问层。
我想指出，在 MVC 组件之一中找到混合业务逻辑和数据访问的代码并不罕见，特别是如果应用程序不是使用多层架构的。然而，在大多数企业应用程序中，您通常会发现多层体系结构在表示层中具有 MVC 体系结构。
As a couple of answers have pointed out, I believe there is some some misunderstanding of multi tier vs MVC architecture.
Multi tier architecture involves breaking your application into tiers/layers (e.g. presentation, business logic, data access)
MVC is an architectural style for the presentation layer of an application. For non trivial applications, business logic/business rules/data access should not be placed directly into Models, Views, or Controllers. To do so would be placing business logic in your presentation layer and thus reducing reuse and maintainability of your code.
The model is a very reasonable choice choice to place business logic, but a better/more maintainable approach is to separate your presentation layer from your business logic layer and create a business logic layer and simply call the business logic layer from your models when needed. The business logic layer will in turn call into the data access layer.
I would like to point out that it is not uncommon to find code that mixes business logic and data access in one of the MVC components, especially if the application was not architected using multiple tiers. However, in most enterprise applications, you will commonly find multi tier architectures with an MVC architecture in place within the presentation layer.
这是一个已回答的问题，但我会给出我的“一分钱”：
业务规则属于模型。
“模型”始终由以下部分组成（逻辑上或物理上分离）：
业务规则存在于域模型中，以适合表示的形式公开给“表示”模型，并且有时在“数据层”中复制（或强制执行）。
This is an answered question, but I'll give my "one cent":
Business rules belong in the model.
The "model" always consists of (logically or physically separated):
Business rules live in the domain model, are exposed in a presentation-suitable form to the "presentation" model and are sometimes duplicated (or also enforced) in the "data layer".
将业务层放入 MVC 项目的模型中是没有意义的。
假设你的老板决定将表示层更改为其他内容，你就完蛋了！业务层应该是一个单独的组件。模型包含来自业务层并传递到视图以显示的数据。例如，在发布时，模型绑定到驻留在业务层中的 Person 类并调用 PersonBusiness.SavePerson(p);其中 p 是 Person 类。这就是我所做的（缺少 BusinessError 类，但也会进入 BusinessLayer）：
It does not make sense to put your business layer in the Model for an MVC project.
Say that your boss decides to change the presentation layer to something else, you would be screwed! The business layer should be a separate assembly. A Model contains the data that comes from the business layer that passes to the view to display. Then on post for example, the model binds to a Person class that resides in the business layer and calls PersonBusiness.SavePerson(p); where p is the Person class. Here's what I do (BusinessError class is missing but would go in the BusinessLayer too):
Q1：
业务逻辑可以分为两类：
域逻辑，例如对电子邮件地址的控制（唯一性、约束等）、获取发票产品的价格，或者根据购物车的总价计算购物车的总价。产品对象。
更广泛和复杂的工作流程，称为业务流程，例如控制学生的注册流程（通常包括多个步骤，需要不同的检查，并且具有更复杂的约束）。
第一个类别属于模型，第二类别属于控制器。这是因为第二类中的情况是广泛的应用程序逻辑，将它们放入模型中可能会混合模型的抽象（例如，不清楚我们是否需要将这些决策放入一个模型类或另一个模型类中，因为它们是相关的）两者皆可！）。
有关模型和控制器之间的具体区别，请参阅此答案，此链接了解非常精确的定义，还有这个链接 一个不错的 Android 示例。
重点是，上面“Mud”和“Frank”提到的注释都可以是真实的，也可以是“Pete”的注释（业务逻辑可以根据业务逻辑的类型放在模型或控制器中）。
最后，请注意 MVC 因上下文而异。例如，在 Android 应用程序中，建议使用一些与基于 Web 的定义不同的替代定义（请参阅此 帖子< /a> 例如）。
Q2：
业务逻辑更通用，（如上面提到的“decyclone”）我们有以下关系：
Q1:
Business logics can be considered in two categories:
Domain logics like controls on an email address (uniqueness, constraints, etc.), obtaining the price of a product for invoice, or, calculating the shoppingCart's total price based of its product objects.
More broad and complicated workflows which are called business processes, like controlling the registration process for the student (which usually includes several steps and needs different checks and has more complicated constraints).
The first category goes into model and the second one belongs to controller. This is because the cases in the second category are broad application logics and putting them in the model may mix the model's abstraction (for example, it is not clear if we need to put those decisions in one model class or another, since they are related to both!).
See this answer for a specific distinction between model and controller, this link for very exact definitions and also this link for a nice Android example.
The point is that the notes mentioned by "Mud" and "Frank" above both can be true as well as "Pete"'s (business logic can be put in model, or controller, according to the type of business logic).
Finally, note that MVC differs from context to context. For example, in Android applications, some alternative definitions are suggested that differs from web-based ones (see this post for example).
Q2:
Business logic is more general and (as "decyclone" mentioned above) we have the following relation between them:
为什么不引入一个服务层呢？那么你的控制器将变得精简且更具可读性，那么你的所有控制器功能将是纯粹的操作。您可以在服务层中根据需要分解业务逻辑。代码复用性高。对模型和存储库没有影响。
Why don't you introduce a service layer. then your controller will be lean and more readable, then your all controller functions will be pure actions. you can decompose business logic as you much as you need within service layer . code reusability is hight . no impact on models and repositories.
模型 = CRUD 数据库操作的代码。
控制器 = 响应用户操作，并将数据检索或删除/更新的用户请求传递给模型，遵守组织特定的业务规则。这些业务规则可以在辅助类中实现，或者如果它们不太复杂，则可以直接在控制器操作中实现。控制器最终要求视图更新自身，以便以新的显示形式或“已更新，谢谢”等消息的形式向用户提供反馈，
View = 基于查询生成的 UI模型。
关于业务规则应该放在哪里，没有硬性规定。在某些设计中，它们进入模型，而在其他设计中，它们包含在控制器中。但我认为最好将它们与控制器放在一起。让模型只关心数据库连接。
Model = code for CRUD database operations.
Controller = responds to user actions, and passes the user requests for data retrieval or delete/update to the model, subject to the business rules specific to an organization. These business rules could be implemented in helper classes, or if they are not too complex, just directly in the controller actions. The controller finally asks the view to update itself so as to give feedback to the user in the form of a new display, or a message like 'updated, thanks', etc.,
View = UI that is generated based on a query on the model.
There are no hard and fast rules regarding where business rules should go. In some designs they go into model, whereas in others they are included with the controller. But I think it is better to keep them with the controller. Let the model worry only about database connectivity.