controller的含义
===========

很高兴，我们的router模块变成了
```js
//user.ts
const user = async (ctx: any, next: any) => {
    ctx.body = 'hello user';
}

const userInfo = async (ctx: any, next: any) => {
    ctx.body = 'hello userinfo';
}

export default {
    'get /': user,
    'get /userinfo': userInfo
}
```
这样的一种形式，我们想要增加一个模块的时候只需要添加一个文件，并做好映射导出就可以了，极大的增加了我们的**开发效率，更加的规范化，bug就意味着更少**。


但是，这样的一种形式仍然有问题没解决。

从宏观上来看我们处理业务的流程是：

```用户请求->到达router->处理业务->返回请求给用户```

但是在业务处理阶段，我们最好，也是最推荐的，就是**把业务逻辑与控制流程分开**。

因此工业中，我们引入``controller``的概念：逻辑控制器。

顾名思义，控制器，主要用于控制逻辑的流程，并不是用来执行真正的逻辑的，那具体什么是流程控制呢？

比如我们**早起刷牙吃早餐去上班**这件事用伪代码表示：

```js
const gotoWorkController = () => {
    起床();//隐藏了如何起床的细节，比如被闹钟吵醒，自然醒
    刷牙();//隐藏了如何刷牙的细节，风骚或者不风骚的刷牙手法
    完成早餐();//隐藏了如何做早餐的各种细节
    去工作();//隐藏了如何去工作的细节，比如坐什么车
}
```


在```gotoWorkController```中，并没有真正出现任何的细节，而是完成主要的流程工作，从起床到去工作，我们通过观察Controller就能知道到底发生了什么。

至于内部细节，我们将会分开实现，放在一个叫service（服务/业务逻辑）的东东里，这就是我们说的**业务逻辑与控制流程分开**。


service的含义
===========

service的出现，主要是为了让**业务逻辑与控制流程分开**，这么做的好处：

- 使得我们的业务逻辑代码能够被极大的复用
- 因为逻辑被拆分成更小的粒度（函数），我们更容易进行单元测试，保证代码质量！

业务逻辑与控制流程分开的意义
===========

很多人不明白，为什么要把事情搞得那么复杂，又分为控制器，又分为业务逻辑。对于还没有太多业务经验的同学来说，肯定要骂街，但是思考一下以下的场景：

**某几个业务流程不同地方部分逻辑相同，都需要调用数据库获取用户的信息**

```
有人访问A地址，调用了A的控制器，控制器中调用了service中的获取用户信息逻辑
有人访问b地址，调用了b的控制器，控制器中调用了service中的获取用户信息逻辑
有人访问c地址，调用了c的控制器，控制器中调用了service中的获取用户信息逻辑
```

这优势就很明显了，当我们把业务逻辑和控制流程分开以后，我们的代码可以做到最大程度的复用。

如果**获取用户信息逻辑**出了问题，我们只需要修改一个serivce就能解决所有的问题了。

- 上一章：[Koa拓展：路由拆分](https://github.com/floveluy/Burnjs/blob/master/example/books/3.%E8%B7%AF%E7%94%B1%E6%8B%86%E5%88%86.md)

- 下一章：- [Controller的实现](https://github.com/floveluy/Burnjs/blob/master/example/books/5.controller%E7%9A%84%E5%AE%9E%E7%8E%B0.md)