The line between controller and model is actually quite clear.
Model is your application's heart. It contains the business/domain logic required to solve the problem your application was written for. The Model is usually layered into several other layers, e.g. persistence, services, domain, etc. It's a common misconception that the Model is just the database, as much as it is a common misconception that the database should be an ActiveRecord.
The controller (and the view) are part of the presentation layer. A controller's sole responsibility is to receive and handle user input directed towards your application and delegate this to the appropriate parts in the model. Nothing more. It should not handle complex application flow or code of your problem domain. You want controllers to be skinny and models fat with logic. The Model should not know about either C or V and you should be able to swap out V and C for a different presentation layer without having to touch your M.
发布评论
评论（1）
控制器和模型之间的界限实际上非常清晰。
模型是应用程序的心脏。它包含解决您的应用程序所针对的问题所需的业务/域逻辑。模型通常分为几个其他层，例如持久性、服务、域等。模型只是数据库是一种常见的误解，就像数据库应该是 ActiveRecord 一样是一种常见的误解。
控制器（和视图）是表示层的一部分。控制器的唯一职责是接收和处理针对应用程序的用户输入，并将其委托给模型中的适当部分。而已。它不应该处理复杂的应用程序流程或问题域的代码。 您希望控制器瘦瘦的，胖的有逻辑。模型不应该知道 C 或 V，并且您应该能够将 V 和 C 替换为不同的表示层，而无需触及 M。
请参阅 企业应用架构模式中的 MVC 摘录
The line between controller and model is actually quite clear.
Model is your application's heart. It contains the business/domain logic required to solve the problem your application was written for. The Model is usually layered into several other layers, e.g. persistence, services, domain, etc. It's a common misconception that the Model is just the database, as much as it is a common misconception that the database should be an ActiveRecord.
The controller (and the view) are part of the presentation layer. A controller's sole responsibility is to receive and handle user input directed towards your application and delegate this to the appropriate parts in the model. Nothing more. It should not handle complex application flow or code of your problem domain. You want controllers to be skinny and models fat with logic. The Model should not know about either C or V and you should be able to swap out V and C for a different presentation layer without having to touch your M.
See MVC Excerpt in Patterns of Enterprise Application Architecture