公司项目可能需要对架构进行重建，老大给了我一个视频让我学习里面的思想，看完后觉得收获很大，主讲人对laravel项目各个层次有很清晰的理解，力求做到职责单一分明，提高可维护性。下面是我看完视频对其内容的大概整理，以及一些自己的见解，有错误的请指出。
Laravel简单架构：
简单的小项目可能会把数据库查询，业务逻辑，数据传给View几乎所有操作都放在Controller，如何项目后期需求变大，最后Controller会变得很臃肿，难懂，不易维护。同样，有些会把所有增删改查，功能类写在Model，Controller再从Model一个个的拿，导致Model很乱，Model有关联表的时候可能会引起一些不必要的数据库查询。
我自己的理解：用美宜佳卖商品给客人来理解，主要Controller是某个加盟商美宜佳门店，View是客人，Model是商品制造工厂（理解有些粗糙）。
Repository（商品仓库）
跟Eloquent/DB操作相关的，例如增删改查，直接和数据库打交道的基础操作抽出来放在Repository中，repository中文是仓库，我的理解就是我们要从Model拿数据，先放在仓库repository中，统一由仓库管理分配，发挥仓库的职责。
Service（总部服务平台）
商业逻辑，不是简单的查询数据，而是特定的任务，例如判断用户是否是会员，设置用户权限等等，这些操作建议放在Service，之后Controller再调用它。
个人理解：
所以在Controller和Model/Eloquent中间垫两层，如果Repository理解为商品仓库的话，我的理解Service是类似总部内部的服务平台，加盟商Controller需要拿商品给客人View，不能直接去食品工厂Model拿，先通过仓库repository，然后总部服务平台Service进行打包啊，整理啊，发车啊（各种任务），最后再给到加盟商Controller手里。
Presenter（充值业务）
一些比较固定，可以单独调用的，可以用Presenter抽出来，不需要让Model去做，下次修改也单独修改Presenter就行了，例如时间戳转成
Y
-
m
-
d H
:
i
:
s
格式，可以单独用Presenter处理后用@inject插入到前端模板，而不是把转化过程写在模板上面。
个人理解：
所以在Controller和View中间可以加一层Presenter，我的理解有点类似：美宜佳商户(Controller)可以给客人(View)充公交卡，这种小事不需要劳费工厂(Model)。
Transformer（快餐小吃人工筛选）
转换器，例如在仓库repository中有一个获取所有用户信息的查询操作：
$this->user->all();
但有些地方我们不需要用到那么多个字段，我只想有name和email字段，难道我要去改all()里面的参数，变成：
$this->user->all(['name','email']);
这样另外的地方又要全部字段，这不就冲突了？这时候Transformer就有用了，其实原理是对
$this
->
user
->
all
()
获得的数据进行筛选后再输出，加了个筛选器。
之后要修改结果字段就直接在transform修改即可，当然还可以额外添加需要的字段：
array_set
