被人忽略的Model

MVC不是一种设计模式,而是一种指导原则,简单讲就是一个应用系统被划分为M(数据模型model)V(视图view)和C(控制器controller)三个部分,每个部分都有比较清晰的职责划分。MVC指导原则下开发的系统代码逻辑清晰,容易扩展并且可复用。

在大多数时候,并没有一种代码级别的约束让你的程序看起来是MVC的思想,多数时候是靠程序员自己的“自觉”,维护一种看起来有序、可复用的模式。

最近我接触到一个系统,发现在controller里有大量的业务逻辑,这些业务逻辑包含了对表单数据的过滤,session的存取,当然还有大量的数据库的读写,甚至包含了数据库的事务,就像是一个“全栈工程师”,包揽了一个项目的大部分业务逻辑,view和model只能望洋兴叹,后来接手的程序员则更是痛苦,因为老板要求系统支持手机端的API,他如果是懒惰的人(也许不是懒惰,只是因为没时间),就会把当前的controller复制一遍,起个新的名字(极可能的名字是原有的action名称后面加上2,好点的加上_mobile),删除传递变量给模板的部分,最后返回一个json格式的字符串;勤奋的人(也许不是勤奋,只是因为重构的时间比较充足)会新建一个service层,把大部分的业务逻辑转移到service里,然后新建一个action,使得原来的action和手机端对应的action都调用service里的方法。当然也有自作聪明的人会修改原来的业务逻辑,在原有的action里加上了浏览器user-agent判断。

重购前的代码就像是这样:

class UserController{
    
    function login(){
        $name = $this->request()->get("name");
        $password = $this->request()->get("passoword");
        $user = new User();
        $success = $user->where("name",$name)->where('password',$password)->find();
        if($success){
            return redirect("home");
        }else{
            return redirect('login','login fail');
        }
    }
}

这样的代码似乎并没有什么问题,但是当业务逻辑比较复杂的时候,对于名字为login的action责任就太大了,而且我在新的接口里用到登录的逻辑时,就必须要复制代码:

class UserController{
    
    function login(){
        $name = $this->request()->get("name");
        $password = $this->request()->get("passoword");
        $user = new User();
        $success = $user->where("name",$name)->where('password',$password)->find();
        if($success){
            return redirect("home");
        }else{
            return redirect('login','login fail');
        }
    }

    function login_mobile(){
        $name = $this->request()->get("name");
        $password = $this->request()->get("passoword");
        $user = new User();
        $success = $user->where("name",$name)->where('password',$password)->find();
        return json_encode(array(
            'success'   => $success
        ));
    }
}

所以现在我们作了以下的重构:

class UserController{
    function __construct()
    {
        $this->service = new Service();
    }

    function login(){
        $name = $this->request()->get("name");
        $password = $this->request()->get("passoword");
        if($this->service->has($name,$password)){
            return redirect("home");
        }else{
            return redirect('login','login fail');
        }
    }

    function login_mobile(){
        $name = $this->request()->get("name");
        $password = $this->request()->get("passoword");
        $success = $this->service->has($name,$password);
        return json_encode(array(
            'success'   => $success
        ));
    }
}

我们把可能非常冗繁的数据库操作逻辑转移到了service类里面。这样,controller只是负责转发数据,并不负责任何业务逻辑,实际上,它的职责只该包括:

  1. 过滤(验证)数据。
  2. 传递数据。
    要注意的是,传递的数据应该包括request,session和cookie中的数据,不要在service里去操作request,session和cookie。因为永远都不知道这个职能单一的service还会被谁调用,也许是命令行(CLI)模式下调用也不一定。

基于MVC思想开发的框架很多,如laravel、CI、Yii Framework,thinkphp(TP)等。许多时候开发者纠缠于使用哪一个框架能更好的开发,业务逻辑能更加清晰,其实哪一个框架都可以,对代码的控制才是关键。

在一些时候,框架的业务逻辑是在model里,有时是在service里。封装具体的业务逻辑的类名并不真的重要,思想才最重要。

就像Yii Framework官网所说的:

In a well-designed MVC application, controllers are often very thin, containing probably only a few dozen lines of code; while models are very fat, containing most of the code responsible for representing and manipulating the data.

推荐阅读更多精彩内容