mirror of
https://github.com/chai2010/advanced-go-programming-book.git
synced 2025-05-24 04:22:22 +00:00
add controller logic dao
This commit is contained in:
parent
86d175d862
commit
458e09e3ca
@ -6,11 +6,11 @@
|
|||||||
2. 视图(View) - 界面设计人员进行图形界面设计。
|
2. 视图(View) - 界面设计人员进行图形界面设计。
|
||||||
3. 模型(Model) - 程序员编写程序应有的功能(实现算法等等)、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
|
3. 模型(Model) - 程序员编写程序应有的功能(实现算法等等)、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
|
||||||
|
|
||||||
随着时代的发展,前端也变成了越来越复杂的工程,为了更好地工程化,现在更为流行的一般是前后分离的架构。可以认为前后分离是把 V 层从 MVC 中抽离单独成为项目。这样一个后端项目一般就只剩下 M 和 C 层了。前后端之间通过 ajax 来交互,有时候要解决跨域的问题,但也已经有了较为成熟的方案:
|
随着时代的发展,前端也变成了越来越复杂的工程,为了更好地工程化,现在更为流行的一般是前后分离的架构。可以认为前后分离是把 V 层从 MVC 中抽离单独成为项目。这样一个后端项目一般就只剩下 M 和 C 层了。前后端之间通过 ajax 来交互,有时候要解决跨域的问题,但也已经有了较为成熟的方案。下面是一个前后分离的系统的简易交互图。
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
事实上,即使是简单的项目,业界也并没有完全遵守 MVC 功能提出者对于 M 和 C 所定义的分工。有很多公司的项目会在 controller 层塞入大量的逻辑,在 model 层就只管理数据的存储。这往往来源于对于 model 层字面含义的某种擅自引申理解。认为字面意思,这一层就是处理某种建模,而模型是什么?就是数据呗!
|
图里的 vue 和 react 是现在前端界比较流行的两个框架,因为我们的重点不在这里,所以前端项目内的组织我们就不强调了。事实上,即使是简单的项目,业界也并没有完全遵守 MVC 功能提出者对于 M 和 C 所定义的分工。有很多公司的项目会在 controller 层塞入大量的逻辑,在 model 层就只管理数据的存储。这往往来源于对于 model 层字面含义的某种擅自引申理解。认为字面意思,这一层就是处理某种建模,而模型是什么?就是数据呗!
|
||||||
|
|
||||||
这种理解显然是有问题的,业务流程也算是一种“模型”,是对真实世界用户行为或者既有流程的一种建模,并非只有按格式组织的数据才能叫模型。不过按照 MVC 的创始人的想法,我们如果把和数据打交道的代码还有业务流程全部塞进 MVC 里的 M 层的话,这个 M 层又会显得有些过于臃肿。对于复杂的项目,一个 C 和一个 M 层显然是不够用的,现在比较流行的纯后端 api 模块一般采用下述划分方法:
|
这种理解显然是有问题的,业务流程也算是一种“模型”,是对真实世界用户行为或者既有流程的一种建模,并非只有按格式组织的数据才能叫模型。不过按照 MVC 的创始人的想法,我们如果把和数据打交道的代码还有业务流程全部塞进 MVC 里的 M 层的话,这个 M 层又会显得有些过于臃肿。对于复杂的项目,一个 C 和一个 M 层显然是不够用的,现在比较流行的纯后端 api 模块一般采用下述划分方法:
|
||||||
|
|
||||||
@ -20,7 +20,7 @@
|
|||||||
|
|
||||||
每一层都会做好自己的工作,然后用请求当前的上下文构造下一层工作所需要的结构体或其它类型参数,然后调用下一次的函数。在工作完成之后,再把处理结果一层层地传出到入口。
|
每一层都会做好自己的工作,然后用请求当前的上下文构造下一层工作所需要的结构体或其它类型参数,然后调用下一次的函数。在工作完成之后,再把处理结果一层层地传出到入口。
|
||||||
|
|
||||||
TODOTODO,这里是一个请求,从 c->l->d 的流程,和返回的示意图。
|

|
||||||
|
|
||||||
划分为 CLD 三层之后,在 C 层我们可能还需要同时支持多种协议。本章前面讲到的 thrift、gRPC 和 http 并不是一定只选择其中一种,有时我们需要支持其中的两种,比如同一个接口,我们既需要效率较高的 thrift,也需要方便 debug 的 http 入口。这样请求的流程会变成下面这样:
|
划分为 CLD 三层之后,在 C 层我们可能还需要同时支持多种协议。本章前面讲到的 thrift、gRPC 和 http 并不是一定只选择其中一种,有时我们需要支持其中的两种,比如同一个接口,我们既需要效率较高的 thrift,也需要方便 debug 的 http 入口。这样请求的流程会变成下面这样:
|
||||||
|
|
||||||
|
BIN
images/ch6-08-controller-logic-dao.png
Normal file
BIN
images/ch6-08-controller-logic-dao.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 38 KiB |
25
images/ch6-controller-logic-dao-storage.plantuml
Normal file
25
images/ch6-controller-logic-dao-storage.plantuml
Normal file
@ -0,0 +1,25 @@
|
|||||||
|
' Copyright 2018 <cao1988228{AT}163.com>. All rights reserved.
|
||||||
|
' Use of this source code is governed by a Apache
|
||||||
|
' license that can be found in the LICENSE file.
|
||||||
|
|
||||||
|
@startuml controller-logic-dao
|
||||||
|
scale 1366*768
|
||||||
|
|
||||||
|
|
||||||
|
activate Controller
|
||||||
|
Controller -> Controller: validate input
|
||||||
|
|
||||||
|
Controller -> Logic : build struct needed by logic, call function in logic
|
||||||
|
activate Logic
|
||||||
|
Logic -> Logic: logic check, use design patterns to work
|
||||||
|
Logic -> Dao: call save order func
|
||||||
|
activate Dao
|
||||||
|
Dao -> Storage: save order
|
||||||
|
Storage -> Dao: save order result
|
||||||
|
Dao -> Logic: return save result
|
||||||
|
deactivate Dao
|
||||||
|
Logic -> Controller: return result
|
||||||
|
deactivate Logic
|
||||||
|
|
||||||
|
deactivate Controller
|
||||||
|
@enduml
|
Loading…
x
Reference in New Issue
Block a user