php model层怎么写逻辑,目前用php框架的话，大家会把逻辑写到model中吗？

这个涉及到面向对象设计的一个问题。Robert·C·Martin在面向对象设计的原则里面提出SOLID原则，具体内容可以参考维基百科的这个链接SOLID面向对象设计

那么，控制器的作用在于对视图和业务模块进行调度，所以根据单一功能原则,控制器不应该包含业务逻辑的处理功能，也就是说业务逻辑不应该放在控制器部分进行处理。

那业务逻辑是不是应该放在Model部分进行处理呢？我们在观察Model的这个概念的时候，会发现，这个概念是比较含糊的。因为业务逻辑的处理起码分为两个部分，第一个部分，数据存取；第二个部分，逻辑操作。根据我的理解，我个人认为，Model层的工作在于业务逻辑的实现，而不应该进行数据存取。

我们反过来想这个问题，如果把业务逻辑和数据存取耦合在一个类里面，会存在什么问题？那么，一个显而易见的问题就是，当我们的数据源在未来架构中发生变化和调整的时候，我们就必须修改Model类以适应这种变化，而这应该是违反开闭原则的，也违反单一功能原则。因此，合理的做法应该是，将数据存取单独的封装成另外一个类。

我们进行程序设计的时候，除了考虑基本的功能实现以外，还必须考虑代码的可维护性，程序的可扩展性这些问题，因此程序要做到“高内聚，低耦合”，理想的情况是，当需求和架构发生变化的时候，我们不应该修改既定代码，而增加新代码来反应系统面临的变化；不同模块之间，依靠接口编程进行互相调用，而封闭模块的内部实现。

因此，一般而言，控制器只单独处理视图和Model的调用，依靠接口进行数据传递工作，视图和Model的内部实现对于控制器应该是封闭的。在MVC的设计原则中，有一条获得比较多认可的原则就是Thin Controller Fat Model。在实践中，一些业务逻辑的处理结果可能通过常驻进程和定时任务进行处理，而控制器只需要跟静态缓存进行沟通，即可快速的做出响应。因此，业务逻辑处理是一个单独的系统。

当然，系统分层和解耦，会额外带来对象管理和设计上的复杂度和负担。MVC模式并不是适合一切情况的最佳模式，对于中小型系统，业务逻辑不复杂的情况下，其实使用Model1方式进行系统设计，即一个前端展示系统和一个后端数据操作系统即可。而对于需要长期可动态维护、进行服务扩展、灵活配置系统的软硬件资源的系统，则需要进行充分的封装解耦以隔离问题。