被人忽略的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.