php 分层,php 项目如何分层

背景：项目比较大 前后端分离

框架：thinkphp

问题：传统的mvc模式 感觉已经不能适应了 因为项目已经不是简单的curd 涉及很多复杂的逻辑

1 控制器 如何优雅点 传统的代码都是写在控制器 控制器直接就进行业务处理了 很难维护 我打算引入一个逻辑层 控制器 负责调动逻辑层 逻辑层记性复杂的代码 但是这样一想 只是把控制器的复杂转移到了逻辑层而已 不知道各位有什么建议 或者开源的代码提供学习呢？

我自己的想法

controller

User.php

logic

UserLogic.php

BookLogic.php

Model

User.php

我觉得除了model的东西能复用 logic的代码其实复用性很低 甚至没有 因为你每一个接口其实就是实现一个功能的 那么逻辑层其实就是为了实现你这个功能而存在的 所以也不存在bookLogic可以复用UserLogic的东西 这种跨logic的调用 也会带来一系列麻烦 依赖性强 如果改动了 会牵一发动全身

回答

关注下 DDD 和 微服务，你考虑的问题已经超出应用分层的范畴了，应该从应用系统设计上来考虑这些问题

本身逻辑相之对应的就是业务细节，大部分情况下不存在复用。

Controller 控制器，的作用就是接受请求参数、验证请求参数(在 Laravel 中应当首选使用自定义 Request)、调用 Service 、返回结果给用户

Service 服务，的作用就是在 Controller 把数据传递之后，通过调用 Model 或者 Repository 将数据库查出，后调用 Model 保存数据，一个 Service 对应的就应该是一个业务，不应该把多个业务写道同一个 Service。

Repository 仓库，如其名字，就是一个仓库，通过调用 Model 来查询数据(仅负责查询)，其中一些方法就可以被抽象，比如 find、all、page，Repository 应该与 Model 相对应。

Action 动作(可选，因为多数情况下 Service 可以替代它)，这里也是作为业务和Model的中间层，可以封装 Model 的增、删、改操作，Action 应该与 Model 相对应。

Model 模型，这一层，不应该直接与 Controller 直接进行互动。C ->(Service|Repository|Action) -> Model，Model 始终不应该扩张，只做模型该做的事情，比如，查询域、转换器、关联关系。

试想，如果没有 Service 和 Repository ，你的 Controller 会包含多少内容。