比如教程中提到的活跃用户方法，放在 ActiveUserHelper 中是因为涉及到缓存和控制台命令，还是说因为获取活跃用户这个方法相对与普通的 Model 方法多了很多代码逻辑判断？
是不是我可以这样判断：
简单的三五句可以写完的几乎每个 Model 都有的方法，就放在 Model 中，属于某个特定业务的方法，可能会随着业务的改变直接删除和弃用的方法就写一个专用的 ModelHelper？
把整个 Laravel 代码放到一个巨大的 PHP 文件中，是可以执行的，那么问题来了：为啥要费劲分成那么多文件呢？
因为可读性高。
ActiveUserHelper 只不过教授一个简单易用的方案，让你的 Model 文件不至于变得太大。知道这个逻辑后，相信你应该可以灵活运用了。
至于划分的逻辑，如果是你个人项目，只要你自己觉得合理即可。如果是团队项目，跟团队成员约定好，即可。
谁都能随便写出机器阅读的代码，而真正优秀的开发者，写出来的代码是连傻瓜都能看懂的。
我个人比较崇尚 代码是写给人看的，所以比较推荐简单直观的程序构建方案，课程中也沿用了我这一思维。
把整个 Laravel 代码放到一个巨大的 PHP 文件中，是可以执行的，那么问题来了：为啥要费劲分成那么多文件呢？
因为可读性高。
ActiveUserHelper 只不过教授一个简单易用的方案，让你的 Model 文件不至于变得太大。知道这个逻辑后，相信你应该可以灵活运用了。
至于划分的逻辑，如果是你个人项目，只要你自己觉得合理即可。如果是团队项目，跟团队成员约定好，即可。
谁都能随便写出机器阅读的代码，而真正优秀的开发者，写出来的代码是连傻瓜都能看懂的。
我个人比较崇尚 代码是写给人看的，所以比较推荐简单直观的程序构建方案，课程中也沿用了我这一思维。
@阿伦
有一种模式叫
Skinny Models, Skinny Controllers, Fat Services
不要把太多的逻辑放在Model和Controller里，你可以引进Service Layer或者Repository Pattern或者Helpers/Trait，可读性高，bug少，容易测试等等.
粤ICP备18099781号-6
|
粤公网安备 44030502004330号
|
违法和不良信息举报
由 Summer 设计和编码 ❤
请登录
关于 LearnKu
@阿伦
有一种模式叫
不要把太多的逻辑放在Model和Controller里，你可以引进Service Layer或者Repository Pattern或者Helpers/Trait，可读性高，bug少，容易测试等等.