这个涉及到面向对象设计的一个问题。Robert·C·Martin在面向对象设计的原则里面提出SOLID原则,具体内容可以参考维基百科的这个链接SOLID面向对象设计
那么,控制器的作用在于对视图和业务模块进行调度,所以根据单一功能原则,控制器不应该包含业务逻辑的处理功能,也就是说业务逻辑不应该放在控制器部分进行处理。
那业务逻辑是不是应该放在Model部分进行处理呢?我们在观察Model的这个概念的时候,会发现,这个概念是比较含糊的。因为业务逻辑的处理起码分为两个部分,第一个部分,数据存取;第二个部分,逻辑操作。根据我的理解,我个人认为,Model层的工作在于业务逻辑的实现,而不应该进行数据存取。
我们反过来想这个问题,如果把业务逻辑和数据存取耦合在一个类里面,会存在什么问题?那么,一个显而易见的问题就是,当我们的数据源在未来架构中发生变化和调整的时候,我们就必须修改Model类以适应这种变化,而这应该是违反开闭原则的,也违反单一功能原则。因此,合理的做法应该是,将数据存取单独的封装成另外一个类。
我们进行程序设计的时候,除了考虑基本的功能实现以外,还必须考虑代码的可维护性,程序的可扩展性这些问题,因此程序要做到“高内聚,低耦合”,理想的情况是,当需求和架构发生变化的时候,我们不应该修改既定代码,而增加新代码来反应系统面临的变化;不同模块之间,依靠接口编程进行互相调用,而封闭模块的内部实现。
因此,一般而言,控制器只单独处理视图和Model的调用,依靠接口进行数据传递工作,视图和Model的内部实现对于控制器应该是封闭的。在MVC的设计原则中,有一条获得比较多认可的原则就是Thin Controller Fat Model。在实践中,一些业务逻辑的处理结果可能通过常驻进程和定时任务进行处理,而控制器只需要跟静态缓存进行沟通,即可快速的做出响应。因此,业务逻辑处理是一个单独的系统。
当然,系统分层和解耦,会额外带来对象管理和设计上的复杂度和负担。MVC模式并不是适合一切情况的最佳模式,对于中小型系统,业务逻辑不复杂的情况下,其实使用Model1方式进行系统设计,即一个前端展示系统和一个后端数据操作系统即可。而对于需要长期可动态维护、进行服务扩展、灵活配置系统的软硬件资源的系统,则需要进行充分的封装解耦以隔离问题。