update layout section

ch6-web/ch6-08-layout-of-web-project.md

@@ -1,14 +1,18 @@
 # 6.8. layout 常见大型 web 项目分层
 
-流行的 web 框架大多数是 MVC 框架，MVC 这个概念最早由Trygve Reenskaug在1978年提出，为了对 GUI 类型的应用进行方便扩展，将程序划分为：
+流行的 web 框架大多数是 MVC 框架，MVC 这个概念最早由 Trygve Reenskaug 在 1978 年提出，为了能够对 GUI 类型的应用进行方便扩展，将程序划分为：
 
 1. 控制器（Controller）- 负责转发请求，对请求进行处理。
 2. 视图（View） - 界面设计人员进行图形界面设计。
 3. 模型（Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
 
-随着时代的发展，前端也变成了越来越复杂的工程，为了更好地工程化，现在更为流行的一般是前后分离的架构。可以认为前后分离是把 V 层从 MVC 中抽离单独成为项目。这样一个后端项目一般就只剩下 M 和 C 层了。事实上，即使是简单的项目，业界也并没有完全遵守 MVC 功能提出者对于 M 和 C 所定义的分工。有很多公司的项目会在 controller 层塞入大量的逻辑，在 model 层就只管理数据的存储。这往往来源于对于 model 层字面含义的某种擅自引申理解。认为字面意思，这一层就是处理某种建模，而模型是什么？就是数据呗！
+随着时代的发展，前端也变成了越来越复杂的工程，为了更好地工程化，现在更为流行的一般是前后分离的架构。可以认为前后分离是把 V 层从 MVC 中抽离单独成为项目。这样一个后端项目一般就只剩下 M 和 C 层了。
 
-这种理解显然是有问题的，业务流程也算是一种“模型”，而并非只有按格式组织的数据才能叫模型。MVC 的创始人应该是这么想的。按照原始的分工，MVC 里的 M 层似乎就有一些过于臃肿了。对于更为复杂的项目，一个 C 和一个 M 层显然是不够用的，现在比较流行的 api(不包含界面) 项目一般是下面这样划分的：
+TODOTODO，这里是前后分离的架构图
+
+事实上，即使是简单的项目，业界也并没有完全遵守 MVC 功能提出者对于 M 和 C 所定义的分工。有很多公司的项目会在 controller 层塞入大量的逻辑，在 model 层就只管理数据的存储。这往往来源于对于 model 层字面含义的某种擅自引申理解。认为字面意思，这一层就是处理某种建模，而模型是什么？就是数据呗！
+
+这种理解显然是有问题的，业务流程也算是一种“模型”，是对真实世界用户行为或者既有流程的一种建模，并非只有按格式组织的数据才能叫模型。不过按照 MVC 的创始人的想法，我们如果把和数据打交道的代码还有业务流程全部塞进 MVC 里的 M 层的话，这个 M 层又会显得有些过于臃肿。对于复杂的项目，一个 C 和一个 M 层显然是不够用的，现在比较流行的纯后端 api 模块一般采用下述划分方法：
 
 1. Controller，与上述类似，服务入口，负责处理路由，参数校验，请求转发
 2. Logic/Service，逻辑(服务)层，一般是业务逻辑的入口，可以认为从这里开始，所有的请求参数一定是合法的。业务逻辑和业务流程也都在这一层中。常见的设计中会将该层称为 Business Rules。
@@ -62,8 +66,14 @@ func HTTPCreateOrderHandler(wr http.ResponseWriter, r *http.Request) {
 
 TODOTODO，这里是带上 middleware 之后的请求图。
 
-middleware 是和 http 协议强相关的，但 middleware 显然不应该和协议强绑定。如果我们坚持用之前的 middleware 方案的话，这里 thrift 的请求路线就还需要再多写一套 thrift 自己的 middleware。
+之前我们学习的 middleware 是和 http 协议强相关的，在项目支持了多种协议之后，这种和协议强绑定的 middleware 成为了我们的瓶颈。如果我们坚持用之前的 middleware 方案的话，这里 thrift 的请求路线就还需要再多写一套 thrift 自己的 middleware，将业务无关的代码重复地写了两遍。请求流程变成了这样：
+
+TODOTODO，这里是加入 middleware 之后的多协议框架请求处理流程。
 
 这也是很多企业项目所面临的真实问题，遗憾的是开源界并没有这样方便的多协议 middleware 解决方案。
 
+怎么解决这个问题呢，也不麻烦。把协议处理从 controller 中独立出去，新的 middleware 写在协议处理层后面。如图：
+
+TODOTODO，这里有图，是将 middleware 后置之后的请求处理流程。
+
 是不是感觉项目变的越来越复杂了？真实的项目就是这样一步一步，根据需求演进而来的。