遵循Crudy By Design模式的控制器臃肿与SRP原则困惑

先搞懂Crudy到底适合啥 #

Crudy的核心优势是减少同构CRUD场景的路由冗余——比如你对用户、订单这类标准资源做增删改查，用/{resource}配合POST/GET/PUT/DELETE区分操作，能省掉大量重复的路由定义，逻辑也高度统一。但它的前提是：操作的是同一类资源，参数、业务逻辑差异极小。

你现在硬把15个参数、逻辑完全不同的第三方API塞进同一个store路由，等于把异构操作强套进同构框架里，控制器不臃肿才怪，这根本不是Crudy的正确用法。

哪种方式更符合单一职责原则？ #

答案很明确：单独路由+独立控制器方法更贴合SRP。

• 每个独立方法只负责一个第三方API的调用：参数验证、错误处理都是针对性的，一个方法只干一件事，出问题了直接找对应方法，维护成本极低。
• 统一/{type}路由的控制器：一个方法要处理15种分支判断、15套验证规则，相当于把15个职责硬塞到一个函数里，完全违反了“一个类/方法只负责单一功能”的原则，这就是你觉得难维护的根源。

想兼顾简洁性和SRP？试试这些调整 #

如果不想写15个重复的路由定义，又不想违背SRP，可以这么搞：

• 路由层做分发：定义POST /third-party/{type}，然后在路由里把不同的type直接映射到对应的处理类（比如type=user对应UserApiHandler），控制器只做转发，不写具体逻辑。
• 抽离验证规则：每个API请求对应一个独立的请求验证类（比如CreateUserRequest），把验证规则写在请求类里，控制器里只需调用$this->validate(new CreateUserRequest())，不用堆一堆分支判断。
• 统一错误处理：把try/catch和错误返回逻辑抽成基类方法或者全局中间件，每个处理逻辑里直接复用，不用重复写。

说白了，Crudy不是万能的，它只适合标准CRUD场景。你的需求是调用异构第三方API，单独路由+独立处理逻辑才是更合理的选择，既符合SRP，也方便维护。

内容的提问来源于stack exchange，提问作者SamKle3