Laravel 对中大型项目的架构设计

本文探讨了在Laravel框架中遇到的Model臃肿和Controller维护困难的问题,提出了一种适用于中大型项目的架构设计方案,包括Model、Repository、Service、Controller和Presenter的角色划分,强调了SOLID原则和单元测试的重要性,旨在提高项目的可维护性和可扩展性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

初学laravel时分两种 一种是乖乖的将程序填入MVC架构中 导致controller 和 model异常的臃肿 controller对model高度依赖导致项目在壮大时难以维护. 另一种是不知道程序该写在哪一个class内 毕竟传统 php都是一页一个程序.这里整理出最适合laravel的大型架构,兼具易维护 易扩充 容易重复使用的特点。

受RoR的影响,传统的认为 MVC 就是 model, view, controller :

  • Model 就是数据资料库。
  • Controller负责调用 model 和view。
  • View 就是 HTML。

假如按照传统的MVC概念 那么如下的需求应该怎么写呢?

  1. 发送 短信验证码,使用外部 API。
  2. 使用php调用api完成业务逻辑。
  3. 依照需求将格式显示。
  4. 依需求是进行对转换的格式进行内容筛选。
  5. 依需求显示不同資料。

其中 1, 2属于业务逻辑,而 3, 4, 5 属于显示逻辑,若依照一般对 MVC 的定义,model 是数据资料库,而 view 又是 HTML,以上这些需求都不能写在 model 和 view,只能勉強写在 controller。

因此將大量程序写在 controller,造成 controller 的臃肿和难以维护

Model 过于臃肿

既然逻辑写在 controller 不方便维护,那我將逻辑都写在 model 就好了?

當你将逻辑从 controller 搬到 model 后,虽然 controller 变瘦了,但 model却臃肿,model从原本代表資料庫,現在变成还要负责业务逻辑和显示逻辑,

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值