update layout of web project section

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

@@ -1,8 +1,24 @@
 # 6.8. layout 常见大型 web 项目分层
 
-讲解多协议支持，和没有 v 的 api 分层设计。
+流行的 web 框架大多数是 MVC 框架，MVC 这个概念最早由Trygve Reenskaug在1978年提出，为了对 GUI 类型的应用进行方便扩展，将程序划分为：
 
-当然，如果完全按照 clean architecture 的设计来写代码还是有一些麻烦。在可预见的范围内，我们需要处理的协议类型是有限的。现在互联网公司内部 API 常用的就只有三种 gRPC、thrift 和 http。我们甚至可以通过一些手段，使我们每写一个接口，都可以支持这三种协议。先来把 logic 的入口简化一些，这里我们使用生产环境的 logic 函数签名作为样例：
+1. 控制器（Controller）- 负责转发请求，对请求进行处理。
+2. 视图（View） - 界面设计人员进行图形界面设计。
+3. 模型（Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
+
+随着时代的发展，前端也变成了越来越复杂的工程，为了更好地工程化，现在更为流行的一般是前后分离的架构。可以认为前后分离是把 V 层从 MVC 中抽离单独成为项目。这样一个后端项目一般就只剩下 M 和 C 层了。事实上，即使是简单的项目，业界也并没有完全遵守 MVC 功能提出者对于 M 和 C 所定义的分工。有很多公司的项目会在 controller 层塞入大量的逻辑，在 model 层就只管理数据的存储。这往往来源于对于 model 层字面含义的某种擅自引申理解。认为字面意思，这一层就是处理某种建模，而模型是什么？就是数据呗！
+
+这种理解显然是有问题的，业务流程也算是一种“模型”，而并非只有按格式组织的数据才能叫模型。MVC 的创始人应该是这么想的。按照原始的分工，MVC 里的 M 层似乎就有一些过于臃肿了。对于更为复杂的项目，一个 C 和一个 M 层显然是不够用的，现在比较流行的 api(不包含界面) 项目一般是下面这样划分的：
+
+1. Controller，与上述类似，服务入口，负责处理路由，参数校验，请求转发
+2. Logic/Service，逻辑(服务)层，一般是业务逻辑的入口，可以认为从这里开始，所有的请求参数一定是合法的。业务逻辑和业务流程也都在这一层中。常见的设计中会将该层称为 Business Rules。
+3. DAO/Repository，这一层主要负责和数据、存储打交道。将下层存储以更简单的函数、接口形式暴露给 Logic 层来使用。负责数据的持久化工作。
+
+每一层都会做好自己的工作，然后用请求当前的上下文构造下一层工作所需要的结构体或其它类型参数，然后调用下一次的函数。在工作完成之后，再把处理结果一层层地传出到入口。
+
+TODOTODO，这里是一个请求，从 c->l->d 的流程，和返回的示意图。
+
+讲解多协议支持
 
 ```go
 func CreateOrder(ctx context.Context, req *CreateOrderStruct) (*CreateOrderRespStruct, error) {

ch6-web/ch6-09-interface-and-web.md

@@ -1,10 +1,6 @@
 # 6.8. interface 和 web 编程
 
-我们在之前的小节中看到了如何编写一个 thrift/grpc 协议的服务。在更早的小节中，我们看到了如何编写一个 http 的服务。
+在项目中我们有可能遇到这样的场景：公司内的基础架构因为技术实力原因，最早是从别人那里借来的 kv 存储方案。随着公司的发展，渐渐有大牛加入，想要甩掉这个借来的包袱自研 kv 存储，但接口与之前的 kv 存储不兼容。接入时需要业务改动接入代码，怎么写代码才能让我的核心业务逻辑不受这些外部资源变化影响呢。
-
-如果对于我们的服务模块，提出了更进一步的要求，想要同时支持 http 和 thrift 协议。要怎么办。
-
-公司内的基础架构因为技术实力原因，最早是从别人那里借来的 kv 存储方案。随着公司的发展，渐渐有大牛加入，想要甩掉这个借来的包袱自研 kv 存储，但接口与之前的 kv 存储不兼容。接入时需要业务改动接入代码，怎么写代码才能让我的核心业务逻辑不受这些外部资源变化影响呢。
 
 ## interface 与依赖反转