不怕虎的童鞋们可以看一下基于PHPLaravel实战教程的这一章https://segmentfault.com/a/11..前言经常有人问如何更好地设计目录？代码是如何分发的？如何编写可维护的项目？我写了很多“坏”项目。以下是互联网大佬的文章总结和个人开发经验。Controller控制器，顾名思义，就是一个控制器。当你开始使用PHP时，你知道Controller代表MVC中的C层。MVC本身的概念就是代码分离。它教你如何分离业务。但是，面对业务的不断发展，代码的复杂度也随之增加，功能之间的联系错综复杂。最后，你的MVC变成了下图，那么仅仅依靠MVC的设计思想已经不能支撑业务的持续发展了。现在我们重新定义控制器的任务和功能。controller只控制HttpRequest请求，符合SOLID单一功能原则。直接将业务代码写在Controller中，会使代码极其臃肿，难以维护和扩展username=$request->input('username');$user->password=$request->input('password');$result=$user->保存();返回$结果；}}这个时候我们就应该考虑如何把业务代码分离出来，我们引入Service的概念ServiceService本身翻译成一个service将外部方法和公共方法注入到Service中将Service注入到controller中像上图UserControllerrequest=$request;$this->userService=$userService;}浦blicfunctionregister(){//...验证返回$this->userService->register($this->request->all());}}UserService用户名=$用户名；$用户->密码=$密码；$result=$user->保存();返回$结果；}}到此为止，我们至少已经把业务和请求完全分离了，但是还是不尽如人意。如果把所有的业务和CURD都写在Service里，只是把Controller的臃肿转移到Service上，那么Service就没有存在的意义了。因此，我们需要继续划分服务，分离出对数据库的R操作，因为CUD的操作基本不变，R操作会根据业务的复杂程度变得丰富多彩。所以独立R操作。这个时候我们就提到了Repository的概念。Repository我们使用Repository来辅助Model，将相关的查询逻辑封装到不同的repository中，方便逻辑代码的维护。符合SOLID的单一原则和SOLID的依赖倒转。UserControllerrequest=$request;$this->userService=$userService;}公共函数getUserInfo(){//。..验证返回$this->userService->getUserInfo($this->request->all());}}UserServiceuserRepository=$userRepository;}publicfunctiongetUserInfo(){return$this->userRepository->getUserInfo($data);}}UserRepositoryfirst();返回$结果；}}解决R的问题，有人问，能不能放在一起，因为CUD比较统一简单？答案是否定的，我们指的是一个新名词ActionAction这是我看了@Charlie_Jade的文章后了解到的一个独立的操作文件，CreateUser,DeleteUser,UpdateUser等符合SOLIDUserControllerrequest=$request;$this->userService=$userService;}publicfunctionregister(){//...验证返回$this->userService->register($this->request->all());}publicfunctiongetUserInfo(){return$this->userService->getUserInfo($this->request->all());}}UserServiceuserRepository->getUserInfo($数据);}publicfunctionregister(){$result=(newCreateUser())->execute($this->request->all());返回$结果；}}UserRepositoryfirst();返回$结果;}}CreateUsertel=$data['电话'];$models->password=$data['密码'];$result=$models->保存();返回$结果；}}上面的代码逻辑如下图除了template(V)和其他HTML、JS等，还需要一些其他的规则，或者square为实现部分代码的解耦，以下代码案例不再提供。Common译为公开、常用。在一些开发中，可能需要一些公共方法（不是公共类，比如发送邮件等，使用它们并没有不合适的），比如查询用户余额，查询用户是否注册或在线，生成订单号等。使用Common更简单。它更像是一个公共函数库。在不关心执行结果的时候可以使用Event，但是Event的Listen也提供了队列。Exception不要使用Return返回所有错误消息。在许多情况下，您的回报可能不是您的回报。感谢您阅读本文。如果大家有新的想法，欢迎在评论区讨论。参考Laravel大型项目架构一文：http://oomusou.io/laravel/arc...Laravel程序架构设计思路使用action类：https://segmentfault.com/a/11...Howto使用服务模式？:http://oomusou.io/laravel/ser...SOLID面向对象设计原则：https://www.cnblogs.com/shany...
