关于 l5-repository 开发架构的问题
我实际上是一名产品经理（手动捂脸），只是爱好开发。
产品的方法论：先实现，再优化。但我现在实际上是在学习……所以希望能从多产品线，业务复杂度很高的角度出发去尝试着开发。
基于LARAVEL的开发架构，看了很多的文章，比如
- 单纯的使用l5-repository，貌似很多的业务逻辑会放在Controller层？
- Criteria层用http://blog.zhuanxu.org/2016-12-06-eloquent-6.html 的描述，每单个的复杂业务逻辑就要有一个文件？
按照点灯坊的架构，会有一个Service层来处理业务逻辑。
- 合理的架构是否应该将l5-repository的repository层注入Service？
l5-repository通过
php artisan make:entity Xxxx会在Repositories目录下，分别生成
- XxxxRepository.php
- XxxxRepositoryEloquent.php
- 这两个文件的使用场景有何区别？
http://blog.zhuanxu.org/2016-12-19-doctrin...
- 这篇文章看的我有点蒙逼
恳切的请各位以【多开发组】【多产品线】【业务复杂性高（如 http://blog.zhuanxu.org/2016-12-19-doctrin... ）】等纬度，基于Laravel和l5-repository帮我解惑。谢谢。
关于 LearnKu
粤公网安备 44030502004330号
考虑到 issue和pr的处理情况，我们使用的是 https://github.com/rinvex/repository。不同的实现而已，都是repository层。
我的理解主要有两点，
但是其实对于解耦，我感觉很长一段时间我们还是很依赖Eloquent的，因为他真的是好用，替换成另一套ORM或者直接使用sql，应该是很后面优化的事了。对于我的话，好处就是方便缓存，逼着我们不会把换七八糟的逻辑写在model里面。所以到底用不用，还是挺纠结的，看项目吧。
然后就是对于
貌似很多的业务逻辑会放在Controller层？，这点我不同意，这个跟使不使用repository没什么关系，controller要做的是验证请求，处理业务，返回结构。验证请求有FormRequest, 处理业务有event，job，service，太多东西帮助我们处理，controller太大太乱，一定是代码组织的有问题。业务通过各种方式处理了，而不是每单个的复杂业务逻辑就要有一个文件？ 按照点灯坊的架构，会有一个Service层来处理业务逻辑。