扫码关注官方订阅号
或者，两者都包括在这里？
走同样的路，发现不同的人生
个人觉得如果业务不复杂的话,把业务逻辑写在model层,C层只写简单的调度...曾经大量的代码与逻辑写在C层,但复用性很差,比如前台与后台要调用一个业务的逻辑基本相似,写在C层就感觉很冗余如果业务复杂,可以再单独分个层专门处理这些逻辑,M层就负责与数据相关的存储即可.
主要看你的业务和代码代码约定，没有固定的用处，要灵活运用。
个人建议每个Model数据模型对应特定的数据表，处理单独的数据表业务，逻辑是业务的实现方式，按照业务去封装，这样便于维护。
M是数据模型，对于C来讲M就相当于是数据库的一张表，只负责存取数据，业务逻辑完全在C中实现，C告诉M存什么数存哪些字段，M负责生成并执行相应的SQL语句然后向C报告结果。
两者皆可。你可以把围绕Model的常见操作写成相应Model类的方法，也可以把它们作为业务逻辑写到Controller的Action里去。
我一般把操作围绕单个Model的CRUD模块直接写成方法，这样在多个Controller里调用（Controller要负责错误提示输出）；涉及多个Model的复杂事务，则完全写在控制器中。
业务逻辑全部放到C层,C层的职责显得太多了,C层专门调用M和V
微信扫码关注PHP中文网服务号
QQ扫码加入技术交流群
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
PHP学习
技术支持
返回顶部
0 
5
591
收藏
个人觉得如果业务不复杂的话,把业务逻辑写在model层,C层只写简单的调度...
曾经大量的代码与逻辑写在C层,但复用性很差,比如前台与后台要调用一个业务的逻辑基本相似,写在C层就感觉很冗余
如果业务复杂,可以再单独分个层专门处理这些逻辑,M层就负责与数据相关的存储即可.
主要看你的业务和代码代码约定，没有固定的用处，要灵活运用。
个人建议每个Model数据模型对应特定的数据表，处理单独的数据表业务，逻辑是业务的实现方式，按照业务去封装，这样便于维护。
M是数据模型，对于C来讲M就相当于是数据库的一张表，只负责存取数据，业务逻辑完全在C中实现，C告诉M存什么数存哪些字段，M负责生成并执行相应的SQL语句然后向C报告结果。
两者皆可。你可以把围绕Model的常见操作写成相应Model类的方法，也可以把它们作为业务逻辑写到Controller的Action里去。
我一般把操作围绕单个Model的CRUD模块直接写成方法，这样在多个Controller里调用（Controller要负责错误提示输出）；涉及多个Model的复杂事务，则完全写在控制器中。
业务逻辑全部放到C层,C层的职责显得太多了,C层专门调用M和V