绝不 使用 Repository??

用 Service 而不是 Repository，用了 Repository 之后无法发挥 Eloquent 的效率了

@leo 用Service不用Repository的话岂不是只是把Controller臃肿的代码转移到Service？

@Juner 那用 Repository 的话岂不是把 Controller 臃肿的代码转移到 Repository？

Controller 到底犯了什么错

我的淺見是：沒有非得用或非得不用
如 Clean Code 中所述，程式都是長出來的，沒有人一開始就知道結果會長怎麼樣，也沒有人知道需求到底會不會變
在我們的項目中一開始是有 Repository 的，在我接手後認為那樣過度設計於是把它拆了
但陸續開發了一年多後為了轉向微服務架構還是慢慢將業務邏輯分離到 Service
等到時候到了就得用了，沒有絕對要用或絕對不用

@leo 不会啊，我是这样设计的，自己写Laravel项目的话

Core和Shell分离，Core写纯逻辑那些，跑Unit Test，然后基于MVC再用Service Repositroy Action辅助，达到解耦和便于维护的目的。

@Juner 所以 Repository 在这里充当了什么角色？目的是什么？

@leo Service 和 Repository 有何不同呢？

@iVerywang Service 负责处理业务逻辑，Repository 负责从数据库里取数据

所有的分层都是为了代码防腐以及分离，不是越多的分层越好，在实际工作中如果你可以预见做的项目规模并不是很大或者更注重开发效率而非开发规范，我的建议是减少分层

小型项目确实不需要Repository，因为商业逻辑并不是那么复杂，但是大中型项目就需要使用Repository了，有些人可能不太清楚Repository中应该放那些代码，Repository中注入Model(当成Eloquent class)，Repository其中方法处理复杂的查询条件拼接，聚合和排序等。大中型项目的层次应该是 Model 注入到Repository ，Repository 注入到 Service（负责商业逻辑） ， Service 注入到Controller。 一切的一切都是为了不违反SOLID原则！

@leo 如果项目中有几百个模型，是否可以考虑使用 Repository？

@akon 模型数量和是否使用 Repository 有什么关系？

目前, 我司项目越来越臃肿, 就采用了Repository

• a. 刚开始curd全部扔 controller 里, 只分了后台, 前台
• b. 后来因为微服务拆分, controller 多了内部接口, 各个服务间相互调用; 内部接口的controller和后台前台, 逻辑都差不多; 所以决定启用service层, 公用逻辑重构到service层
• c. 随着功能越来越多, 复杂查询, 缓存优化等等越来越多; 原来写在service又存在相互嵌套调用问题; 又抽离了 Repository 层, 来放简单查询, 复杂查询, 以及缓存操作

Repository 层怎么说呢, 到用时自然就用上了!
就像小公司无需各种职位, 大小事大家一起干, 也能干好;公司大了, 人多了就不行了, 就要定职位, 定岗位, 职责明确团队运转起来才稳中有快!

@Juner Repositroy 和 Action 的职责有什么区别呢

可以参考微软的The Repository Pattern，解答了为什么需要 R 层