比如教程中提到的活跃用户方法，放在 ActiveUserHelper 中是因为涉及到缓存和控制台命令，还是说因为获取活跃用户这个方法相对与普通的 Model 方法多了很多代码逻辑判断？
是不是我可以这样判断：
简单的三五句可以写完的几乎每个 Model 都有的方法，就放在 Model 中，属于某个特定业务的方法，可能会随着业务的改变直接删除和弃用的方法就写一个专用的 ModelHelper？
@阿伦
有一种模式叫
Skinny Models, Skinny Controllers, Fat Services
不要把太多的逻辑放在Model和Controller里，你可以引进Service Layer或者Repository Pattern或者Helpers/Trait，可读性高，bug少，容易测试等等.
把整个 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
推荐文章：