Laravel 中大型项目面向对象架构

分享 YuxiangDong ⋅ 于 1年前 ⋅ 最后回复由 YuxiangDong 1个月前 ⋅ 6778 阅读

file

我认为这是一个非常利于中大型项目维护的设计思想,推荐给大家。

在传统的MVC架构中增加了3层,以使得代码不同的代码分离。

应用了php的新特性,依赖注入。

具体论文地址 http://oomusou.io/laravel/laravel-architecture/

本文章首发在 Laravel China 社区
本帖已被设为精华帖!
本帖由 Summer 于 1年前 加精
回复数量: 23
  • Summer MOD A Life-long learner.
    1年前

    图片为啥这么小,好文章 :+1:

  • YuxiangDong 生命不息,挖坑不止
    1年前

    @Summer 改了,好像是hub的图片自动会切割缩小,直接引用人家的大图

  • oy476597199
    1年前

    收藏

  • johndoe
    1年前

    有些人 Repository + active record 不好用 :
    https://adamwathan.me/2015/02/14/active-repository-is-an-antipattern/

    大家有什么看法

  • YuxiangDong 生命不息,挖坑不止
    1年前

    @johndoe 所有的设计模式都是在解决问题,你发的这篇论坛的核心观点是需求很简单的时候主题帖中提到的设计模式其实是在增加工作量且危险的,因为需求很简单,就是给文章添加一个评论,并不涉及其他逻辑,这时候使用这种设计模式就显得画蛇添足了。设计模式一定是在适合的场景下使用的。

  • braveTM
    1年前

    我们的项目:weipeiapp.com也会往这个方向重构和发展

  • tonyboy
    1年前

    设计模式终归好,切忌过度设计

  • stoneLon
    1年前

    这篇文章我也看过,不错。

  • GhostCat
    1年前

    不错的文章,model臃肿已经忍耐太久了

  • EdenChan Gravity 'n shit
    1年前

    赞!总结得不错

  • Vanry
    1年前

    符合solid原则 很适合大型项目 要纠结的就是不知道cache是放repo还是service中

  • Linz
    3个月前

    cache放哪里比较合适呢

  • Linz
    3个月前

    @Summer cache放哪里比较合适呢

  • Summer MOD A Life-long learner.
    3个月前

    @Linz 搭车问问题是不礼貌的行为

  • li603674060
    1个月前

    1、把MVC拆成了!MMVVCC
    2、拆的主要目的是解耦
    3、写起来并不友好!

  • YuxiangDong 生命不息,挖坑不止
    1个月前

    @li603674060 加入中间层、中间件很多时候目的是解耦和代码防腐。
    此架构适用的是大型软件团队开发,如果只是做一个小应用,单体应用那么这个架构就是累赘。
    更多分层、分布式、微服务都是解决大型软件和系统遇到的问题,首先你要看清这个架构带给团队什么好处,如果你只是开发个小应用,个人项目不要使用这种架构,因为你的业务都没验证呢谈什么架构呢,快速实现业务为先。

  • li603674060
    1个月前

    @YuxiangDong 1此架构的缓存该怎么处理?2、redis相关的逻辑放在那里?3,model层是不是不用写代码了?4、repo层里面的代码能不能处理多个model?

  • li603674060
    1个月前

    @YuxiangDong 在吗?你用过此架构吗?你们公司的业务架构是什么样子呢?

  • YuxiangDong 生命不息,挖坑不止
    1个月前

    redis看业务把它当做什么用,当做数据库用还是缓存还是队列中间件,但一般应该都在Service。
    model按此架构应该建议只对数据进行定义,而不参与业务逻辑,最好能做的随时抽离出去能作为一个独立的数据提供中心。
    repository其实是可选的,因为很多数据操作框架是继承一个抽象的repository来提供一些通用的操作数据库的方法,如果不使用这种框架其实这一层可以去掉,当然加上也是为了代码职责更清晰,防止代码腐烂,不过这点是可以人为控制的,所以这层在这个架构里看自己喜好吧。
    关于缓存,这个东西太庞大,大型应用从CDN、静态缓存,服务器缓存,页面缓存,HTTP缓存等等,是一个庞大的议题。

  • YuxiangDong 生命不息,挖坑不止
    1个月前

    我司架构属于工作保密内容,只能说我司架构比这还复杂,为的是业务平行扩展和松耦合

  • li603674060
    1个月前

    @YuxiangDong 能方便说下贵公司架构的思想吗?分层大概怎么分的?框架的选择?是否做了前后端完全分离?api的技术选择?

  • li603674060
    1个月前

    @YuxiangDong redis的逻辑放在service也不是太合适的,如果我的项目后期再加了mongodb的话?service太庞大了

  • YuxiangDong 生命不息,挖坑不止
    1个月前

    @li603674060 那你该多看看设计模式,架构和设计模式解决的是不同的问题,你说的这种情况设计模式会有方法来让代码更优雅

暂无评论~~

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