目前用php框架的话，大家会把逻辑写到model中吗？
还是model只做数据的添加删除 修改操作？
如果说是简单 mvc框架 你们把逻辑写在哪里？controller？
还是说自己弄了个逻辑层？
小伙看你根骨奇佳，潜力无限，来学PHP伐。
我支持把业务逻辑封装到Model里，Controller（或称Action）里最好只进行数据转换、整理，确保在Model里尽量不要直接访问GET、POST、SESSION里的数据，一切需要的数据通过方法参数或实例化时传入Model，这样的话代码干净、方便测试，且在你需要编写服务器端的批量维护程序时，仍然可以调用Model来完成业务数据的获取和写入。
同时也赞同 @Airy 的做法。
我一般这么处理的：跟视图相关的逻辑写到 Controller，比如根据登录状态展示不同的页面．跟数据相关的逻辑写到 Model ．
我目前是： Model: 业务逻辑 Contrller: 界面逻辑+基本数据验证
但是发现业务逻辑写到Model里，造成Model非常臃肿， 而且与多种基础设施，第三方Api等等耦合，维护十分不便。 打算重构并独立出一层业务层，放置Model与Model、Model与其他组件的交互逻辑、以及异常处理等。让Model只负责数据验证和CRUD。
我是中间增加一个业务层，控制器只做输入输出，不做业务逻辑，把业务逻辑放在业务层处理，提高代码公用性，model与表一一对应，只做单表查询或者关联查询
这个涉及到面向对象设计的一个问题。Robert·C·Martin在面向对象设计的原则里面提出SOLID原则，具体内容可以参考维基百科的这个链接SOLID面向对象设计
那么，控制器的作用在于对视图和业务模块进行调度，所以根据单一功能原则,控制器不应该包含业务逻辑的处理功能，也就是说业务逻辑不应该放在控制器部分进行处理。
那业务逻辑是不是应该放在Model部分进行处理呢？我们在观察Model的这个概念的时候，会发现，这个概念是比较含糊的。因为业务逻辑的处理起码分为两个部分，第一个部分，数据存取；第二个部分，逻辑操作。根据我的理解，我个人认为，Model层的工作在于业务逻辑的实现，而不应该进行数据存取。
我们反过来想这个问题，如果把业务逻辑和数据存取耦合在一个类里面，会存在什么问题？那么，一个显而易见的问题就是，当我们的数据源在未来架构中发生变化和调整的时候，我们就必须修改Model类以适应这种变化，而这应该是违反开闭原则的，也违反单一功能原则。因此，合理的做法应该是，将数据存取单独的封装成另外一个类。
我们进行程序设计的时候，除了考虑基本的功能实现以外，还必须考虑代码的可维护性，程序的可扩展性这些问题，因此程序要做到“高内聚，低耦合”，理想的情况是，当需求和架构发生变化的时候，我们不应该修改既定代码，而增加新代码来反应系统面临的变化；不同模块之间，依靠接口编程进行互相调用，而封闭模块的内部实现。
因此，一般而言，控制器只单独处理视图和Model的调用，依靠接口进行数据传递工作，视图和Model的内部实现对于控制器应该是封闭的。在MVC的设计原则中，有一条获得比较多认可的原则就是Thin Controller Fat Model。在实践中，一些业务逻辑的处理结果可能通过常驻进程和定时任务进行处理，而控制器只需要跟静态缓存进行沟通，即可快速的做出响应。因此，业务逻辑处理是一个单独的系统。
当然，系统分层和解耦，会额外带来对象管理和设计上的复杂度和负担。MVC模式并不是适合一切情况的最佳模式，对于中小型系统，业务逻辑不复杂的情况下，其实使用Model1方式进行系统设计，即一个前端展示系统和一个后端数据操作系统即可。而对于需要长期可动态维护、进行服务扩展、灵活配置系统的软硬件资源的系统，则需要进行充分的封装解耦以隔离问题。
我这边基本和之前几位说的一致，唯一不同可能是：model层只写针对一张数据表的逻辑代码，而设计到多个表的复杂业务逻辑会写在额外的业务层。
我们的新员工，通常会将逻辑写在 Controller 中，Model基本没有任何内容。
所以，入职说明规定：将业务逻辑写在Model中的
因为：放在 Controller 中，会重复对某些业务逻辑编码。
比如：病人换床会出现在：新入院、老人换床、出院 多个 Controller 中，但是代码只应该写在 病人或者床这个Model中。
引用文字 涉及到多个表的复杂业务逻辑会写在额外的业务层。
这个我还是认为要写在Model中，因为涉及多个Model，所以只能选择某个合适的model写入代码，其他model调用。
不知道是不是有更好的设计方案。
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
我支持把业务逻辑封装到Model里，Controller（或称Action）里最好只进行数据转换、整理，确保在Model里尽量不要直接访问GET、POST、SESSION里的数据，一切需要的数据通过方法参数或实例化时传入Model，这样的话代码干净、方便测试，且在你需要编写服务器端的批量维护程序时，仍然可以调用Model来完成业务数据的获取和写入。
同时也赞同 @Airy 的做法。
我一般这么处理的：跟视图相关的逻辑写到 Controller，比如根据登录状态展示不同的页面．跟数据相关的逻辑写到 Model ．
我目前是： Model: 业务逻辑 Contrller: 界面逻辑+基本数据验证
但是发现业务逻辑写到Model里，造成Model非常臃肿， 而且与多种基础设施，第三方Api等等耦合，维护十分不便。 打算重构并独立出一层业务层，放置Model与Model、Model与其他组件的交互逻辑、以及异常处理等。让Model只负责数据验证和CRUD。
我是中间增加一个业务层，控制器只做输入输出，不做业务逻辑，把业务逻辑放在业务层处理，提高代码公用性，model与表一一对应，只做单表查询或者关联查询
这个涉及到面向对象设计的一个问题。Robert·C·Martin在面向对象设计的原则里面提出SOLID原则，具体内容可以参考维基百科的这个链接SOLID面向对象设计
那么，控制器的作用在于对视图和业务模块进行调度，所以根据单一功能原则,控制器不应该包含业务逻辑的处理功能，也就是说业务逻辑不应该放在控制器部分进行处理。
那业务逻辑是不是应该放在Model部分进行处理呢？我们在观察Model的这个概念的时候，会发现，这个概念是比较含糊的。因为业务逻辑的处理起码分为两个部分，第一个部分，数据存取；第二个部分，逻辑操作。根据我的理解，我个人认为，Model层的工作在于业务逻辑的实现，而不应该进行数据存取。
我们反过来想这个问题，如果把业务逻辑和数据存取耦合在一个类里面，会存在什么问题？那么，一个显而易见的问题就是，当我们的数据源在未来架构中发生变化和调整的时候，我们就必须修改Model类以适应这种变化，而这应该是违反开闭原则的，也违反单一功能原则。因此，合理的做法应该是，将数据存取单独的封装成另外一个类。
我们进行程序设计的时候，除了考虑基本的功能实现以外，还必须考虑代码的可维护性，程序的可扩展性这些问题，因此程序要做到“高内聚，低耦合”，理想的情况是，当需求和架构发生变化的时候，我们不应该修改既定代码，而增加新代码来反应系统面临的变化；不同模块之间，依靠接口编程进行互相调用，而封闭模块的内部实现。
因此，一般而言，控制器只单独处理视图和Model的调用，依靠接口进行数据传递工作，视图和Model的内部实现对于控制器应该是封闭的。在MVC的设计原则中，有一条获得比较多认可的原则就是Thin Controller Fat Model。在实践中，一些业务逻辑的处理结果可能通过常驻进程和定时任务进行处理，而控制器只需要跟静态缓存进行沟通，即可快速的做出响应。因此，业务逻辑处理是一个单独的系统。
当然，系统分层和解耦，会额外带来对象管理和设计上的复杂度和负担。MVC模式并不是适合一切情况的最佳模式，对于中小型系统，业务逻辑不复杂的情况下，其实使用Model1方式进行系统设计，即一个前端展示系统和一个后端数据操作系统即可。而对于需要长期可动态维护、进行服务扩展、灵活配置系统的软硬件资源的系统，则需要进行充分的封装解耦以隔离问题。
我这边基本和之前几位说的一致，唯一不同可能是：model层只写针对一张数据表的逻辑代码，而设计到多个表的复杂业务逻辑会写在额外的业务层。
我们的新员工，通常会将逻辑写在 Controller 中，Model基本没有任何内容。
所以，入职说明规定：将业务逻辑写在Model中的
因为：放在 Controller 中，会重复对某些业务逻辑编码。
比如：病人换床会出现在：新入院、老人换床、出院 多个 Controller 中，但是代码只应该写在 病人或者床这个Model中。
这个我还是认为要写在Model中，因为涉及多个Model，所以只能选择某个合适的model写入代码，其他model调用。
不知道是不是有更好的设计方案。