怎么写一个可维护的项目

前言

经常会有人问

– 目录如何设计比较好？ – 代码如何分布好？ – 怎么写一个可维护的项目?

“烂”项目我也没少写，以下是参考互联网各大佬的文章总结及个人开发经验而来。

Controller顾名思义是控制器，在入门PHP的时候，就知道Controller代表MVC中的C层，MVC本身的概念就代码分离，教你如何如何将业务分开，但面临着业务的不断发展，代码的复杂度也随之提高，功能与功能之间的链接错综复杂，最后你的MVC就变成了下图,所以仅仅依托MVC的设计思想已经无法支撑不断发展的业务。

现在我们将Controller的任务和能力重新定义，控制器仅仅控制Http Reqeust的请求,这样就符合了SOLID 单一功能原则。

直接将业务代码写在Controller中，会使得代码及其臃肿，不易于维护和扩展。

这时就应该思考如何分离业务代码，我们引入Service的概念

Service

Service本身译为服务 – 将外部方法，公共方法注入到Service – 将Service注入到控制器

到现在为止，我们至少将业务与请求彻底分开了。但还是不如人意，如果把所有的业务及CURD全部写在Service中，那只不过是将Controller的臃肿转移到了Service,那Service就没有什么存在意义了。

【CURD】

代表创建（Create）、更新（Update）、读取（Retrieve）和删除（Delete）操作。

所以我们需要继续分割Service，将对数据库的R操作独立出来，因为CUD的操作基本是一贯不变的，而R操作根据业务的复杂度则变的多姿多彩。

所以独立R操作，这个时候我们引用Repository的概念。

Repository

我们使用Repository辅助Model，将相关的查询逻辑封装到不同的repository中，方便逻辑代码的维护。

– 符合SOLID的单一原则 – 符合SOLID的依赖反转

解决了R的问题，有人就问了，难道因为CUD比较统一简单就可以放在一起了吗？

答案是NO，我们引用一个新的名词Action。

Action

独立每个操作文件，例如CreateUser,DeleteUser,UpdateUser

– 符合SOLID的单一原则

示例

目录结构

UserController 控制器