一个菜鸟驿站!

如何少写PHP“烂”代码(一)

PHP 2018-06-19 浏览(2212) 评论(0)
- N +

文章目录 [+]


PHP烂代码

写给初生牛犊不怕虎的童鞋们,大佬可随意摘看

本章基于PHP Laravel


前言

经常会有人问

  • 目录如何设计比较好?

  • 代码如何分布好?

  • 怎么写一个可维护的项目?

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

Controller

104474369-5b209191cb1e6_articlex.png


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

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

104474369-5b209191cb1e6_articlex.png


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

<?php
    namespace App\Http\Controller;

    class UserController extends Controller{

        public function register(Request $request){
            $user = new User();
            $user->username = $request->input('username');
            $user->password = $request->input('password');
            $result = $user->save();

            return $result;
        }

    }

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

Service

Service本身译为服务

  • 将外部方法,公共方法注入到Service

  • 将Service注入到控制器

104474369-5b209191cb1e6_articlex.png


像上图这样。

UserController

<?php
    namespace App\Http\Controller;

    class UserController extends Controller{

        public $request;
        
        protected $userService;
        
        public function __construct(Request $request, UserService $userService)
        {
            $this->request = $request;
            
            $this->userService = $userService;
        }
        
        public function register()
        {
            //... validation
            return $this->userService->register ($this->request->all());
        }
    }

UserService

<?php
    namespace App\Service;

    class UserService{
    
        public function register($data)
        {
            $username = $data['username'];
            $password = $data['password'];
         
            $password = encrypt ($password);
            
            $user = new User();
            $user->username = $username;
            $user->password = $password;
            $result = $user->save();

            return $result;
        }
    }


到现在为止,我们至少将业务请求彻底分开了。但还是不如人意,如果把所有的业务及CURD全部写在Service中,那只不过是将Controller的臃肿转移到了Service,那Service就没有什么存在意义了。所以我们需要继续分割Service,将对数据库的R操作独立出来,因为CUD的操作基本是一贯不变的,而R操作根据业务的复杂度则变的多姿多彩。所以独立R操作。这个时候我们引用Repository的概念。

Repository


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

  • 符合SOLID的单一原则

  • 符合SOLID的依赖反转

104474369-5b209191cb1e6_articlex.png

UserController

<?php
    namespace App\Http\Controller;

    class UserController extends Controller{

        public $request;
        
        protected $userService;
        
        public function __construct(Request $request, UserService $userService)
        {
            $this->request = $request;
            
            $this->userService = $userService;
        }
        
        public function getUserInfo()
        {
            //... validation
            return $this->userService->getUserInfo ($this->request->all());
        }
    }

UserService

<?php
    namespace App\Service;

    class UserService{
    
        public function getUserInfo(UserRepository $userRepository)
        {
            return $this->userRepository->getUserInfo($data);
        }
    }

UserRepository

<?php
    namespace App\Repository;

    class UserRepository{
    
        public function getUserInfo($data)
        {
            $userId = $data['user_id'];
            $result = User::where('id',$userId)->first();
            
            return $result;
        }
    }

解决了R的问题,有人就问了,难道因为CUD比较统一简单就可以放在一起了吗?答案是NO,我们引用一个新的名词Action

Action

......

Event

......

Exception

......


Action以及其他请看下一篇文章。

标签:
作者:猫巷

,

评论列表 (0)条评论

发表评论

召唤伊斯特瓦尔