Laravel程序 最佳实践1 作者: nbboy 时间: 2020-03-14 分类: PHP 评论 # 层的定义 Laravel程序在初始化后，其实相比PHP的其他框架，分层还算比较明确的，正如它的作者所说，是为艺术家写的框架。刚开始的时候，会把所有的代码写在Model里，当代码比较多的时候，往往一个Model代码文件就会膨胀开来。不但Model文件代码非常多，Controller文件代码也非常多，这又会导致复用率非常低。 所以后来在思考一种更好的分层,相信很多从静态语言走过来的读者，比如Java或者C#在开发WEB程序的时候，也是会经典的三层架构MVC。他们更习惯把逻辑代码写在Service层，这样既解决了复用的问题，也解决了把业务逻辑写在Controller层的尴尬。 这时很多人感觉有点疑问，为什么把代码写在Controller层不好？因为根据标准的MVC模型的定义，C这层存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。也就是说，如果把大段的业务逻辑，放在了控制层，不但影响到了复用度，而且导致各层的职责混乱！ 说道MVC,简单复习下MVC的一些概念。其实MVC最早不是产生于WEB程序，而开始是存在于桌面程序中的，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据可以分别用柱状图、饼图来表示。也就是按照标准的定义，我们很多人用的都不是MVC,而是变态版本的MVSC,中间加入一个Service层。这里也顺便说下，其实按照标准，M和V的数据变动是双向的，但是目前我们的WEB做不到这点。 再说回Laravel的情况，Laravel的模型层真的是非常舒服，借助于Eloquent ORM,写起查询来真的是一种享受。借用Laravel官方文档说:"Eloquent ORM 提供了一个漂亮、简洁的 ActiveRecord 实现来和数据库交互"。写过的肯定对他的链式写法映象深刻，这种做法是他的优点之一。有了一个足够强大的模型层，事情真的解决了一大半。**按照DDD的想法，模型应该反映领域驱动的模型，引入Repository层来解决模型的加载和存储问题，引入Service层来解决跨模型的事物处理问题。**对于一般的中小型项目，这种分层已经够用了。分层其实本身很简单，难得是大家都要去遵守这种约定和随着项目不停得去对代码和模块层级，类层级进行审视和重构。 # 框架的破坏 这个是一种糟糕的写法，其实第一次我看到这样写的时候，内心真的10万头草泥马在奔腾。在团队里的很多小伙伴，在Controller层写类似这种代码： AuthController.php中 ```php $token=User::createToken($oldUser); ``` User.php中 ```php protected function createToken($user){ ... } ``` Model类中的保护成员竟然在Controller层进行直接调用，说好的保护呢？？？不过回过头一想，业务程序员是缺乏基础的认识，但是框架怎么能放行这种愚蠢的写法呢！！！ 看看框架做了什么？  哇，原来是这么一回事，果然是框架在作怪。不过仔细想想，作者的想法是不是就是这样？我猜作者的想法只是为了给使用者方便，不用再去"NEW"一个对象，但是的确在这里给使用者放行了这种行为。我想作者可能已经想到了这个问题，只是让使用者自己去做规范吧。 # 总结 其实这篇文字真的没写多少，一方面博客刚恢复访问，总得写点什么。另外一方面后期有很多文章正在构思，小弟文笔不怎么样，只求在这里做一个备忘吧，如果能帮到读者，那我很开心了。其实，Laravel总体来说真的是PHP中的好框架了，但是使用中有很多细节需要考虑和决策，甚至当项目大了之后，也有必要做一定的改造。