绝不 使用 Repository??

这个不对的,常用的方法可以用R层封装起来,不然controller或者model太臃肿了

《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 14
leo

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

1年前 评论

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

1年前 评论
leo

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

1年前 评论
Chasers9527

Controller 到底犯了什么错

1年前 评论
leochien

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

1年前 评论

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

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

1年前 评论
leo

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

1年前 评论

@leo Service 和 Repository 有何不同呢?

1年前 评论
leo

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

1年前 评论

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

1年前 评论

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

1年前 评论

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

3个月前 评论
leo

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

3个月前 评论

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

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

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

3个月前 评论

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!