一点关于"fat model, skinny controller"的思考

导言

想来从事服务器端开发也有将近一年的时间，服务端开发不能忽略的一个架构就是MVC架构，但一开始作为小白的我对这些高大上的概念也是很迷惑，由于很长一段时间应对的业务也是十分简单，业务代码也是流水一样的代码，所以对架构方面的东西接触也不是很多。

而随着过去几个月应对的业务越来复杂，越来越觉得脚本一样的模式写起来非常吃力。

思考

此前用flask和nodejs写过一些接口，这些代码一直是这样的：

# flask
from flask import Flask
app = Flask(__name__)
@app.route('/api/path')
def get_path():
    # do something
    return jsonify({'code':'0'})

// NodeJS express框架
var express = require('express');
var app = new express();
function dosomething(){
    // do something
}
app.route('/api/path').get(dosomething);

以NodeJS express框架搭建的项目为例，项目目录结构只有两层：

app/
    |-- users/
        |-- user.model.js
        |-- user.controller.js
        |-- user.routes.js
    |-- products/
        |-- product.model.js
        |-- product.controller.js
        |-- product.routes.js

其中*.model.js就是对应的是一个数据库的表，*.routes.js文件定义路由，*.controller.js定义了所有的业务逻辑。这种结构一开始工作良好，但随着需求增加，接口代码不断增加，上述每个*.controller.js的代码量急速增加，部分甚至达到一万多行，而且里面基本就是一个接口对应一个函数，每个函数里面就是各种通过对数据库的增删改查操作。

如果只是代码量增多那可以接受，问题是业务需求经常改动，经常牵一发而动全身，此外还要考虑版本的兼容性。有些接口功能、逻辑基本上一样，只有细微的差别，但就是这一点点差别不得不另外再写一个类似的函数，造成代码大量冗余。

几经寻找找到一个思路，就是"fat model,skinny controller"，它的观点是将部分的业务逻辑放到数据模型中定义，作为数据模型类的方法。这对我来说是一种新的尝试，因为使用这种代码编排方法意味着很多类似的代码可以放到model中，从而分担controller的负担。而NodeJS项目中使用的mongoose本身就提供了许多现成的方法。

然而使用了一段时间之后我发现，一个业务操作往往涉及了多个模块的数据库操作，*.model.js因此引入了大量其他模块中的模型，这样的结果反而更加复杂，严重的时候甚至出现了循环引用的问题：一个功能逻辑上本应该属于模型A，然而由于这个功能需要引用模型B，而B模型在其它功能上又引用了模型A。结果就是很多模型相互缠绕在一起。

偶然看到一篇文章，里面指出，"fat model,skinny controller"的分工不是一个好主意，虽然它相比于"fat controller"有优势，但并好不了多少。因为随着功能的增加，开发者不得不将所有的代码放到少数的几个类中，最终造成所谓的"god object"，也就是上帝对象，一个用数千行代码来定义的类实例。

最近在读《企业应用架构模式》这本书，书中总结的一些架构模式启发了我不少。

其中有一部分专门讲数据源架构模式，讲的是业务逻辑应当与数据源适当地隔开。复杂的业务逻辑往往需要隔离数据源层。这一定程度体现了"一个类只做一件事并把它做好"的原则，也就是关注点分离。"fat model,skinny-controller"的模式的问题在于，一个模型既扮演了数据读写的功能又承担了作为业务逻辑主体的角色。这不符合书中提出的分层原则。

前面的文章也指出，我们应当突破框架的局限，突破mvc这种设计模式的限制，使用更多的类取更好地组织你的代码。

重读这篇文章收获颇多，一方面是对fat model的反思，另一方面是对《企业应用架构模式》理解的深入。下一步的方向是将事务脚本的代码转变成为领域模型的形式，削弱业务逻辑对模型层的依赖，增加数据映射器的使用。