html、VO、Controller、Service、Dao、model、DTO、数据库之间的关系

html、VO、Controller、Service、Dao、model、DTO、数据库之间的关系

2023.3.24

---

• VO：View Object（视图对象）
• DTO：Data Transport Object（数据传输对象）

在理解这些关系之前，先让咱来换一个思路，假设一个完整的项目是一个餐厅，即：

项目================ >餐厅
则有：
html================ >菜单
VO================== >订单
Controller=========== >服务员
Service============== >厨师
Dao================== >小工
model================ >食材
数据库================ >食材仓库
DTO================== >成品

整个餐厅的运营流程则为：

1. 顾客进入餐厅------------------------------->用户输入网址
2. 服务员提供菜单---------------------------->Controller发送html
3. 顾客点菜并提交订单给服务员---------->发送VO给Controller
4. 服务员将订单提供给厨师--------------->Controller发送VO给Service处理
5. 厨师通知小工准备食材------------------>Service调用Dao层准备model（厨师通知的信息可认定为条件）
6. 小工去食材仓库拿食材------------------->Dao层连接数据库拿数据
7. 小工拿到食材洗净、切片给厨师------>Dao层拿到数据将其封装为model返回给Service
8. 厨师将各种食材做成成品---------------->Service将Dao层返回的数据加以处理，封装成DTO
9. 厨师将成品交给服务员-------------------->Service将DTO给Controller
10. 服务员将成品交给顾客--------------------->Controller将DTO给用户

由此可得各自的功能为：

html：给用户展示自己的功能，并引导其使用。
VO：用户传输数据的载体，可以理解为 明话。
Controller：控制层，只需要干四件事：从哪拿数据，拿什么数据，调用哪些Service，返回什么数据给前端。
Service：业务逻辑层，拿到数据，处理部分数据，调用哪些Dao，拿到Dao返回的数据，封装处理，返回数据给Controller。
Dao：持久层，根据Service提供的条件，向数据库提取数据，并将数据处理成Service能直接处理的数据。
model：Service、Dao层能直接处理的载体，可以理解为 暗话。
DTO：Service处理所产生的返回数据载体。
数据库：数据集中放置的位置。

一般来讲，VO类只能访问到Service层，不能访问到Dao层；model类只能访问到Service层，不能访问到Controller层，也就是说，暗话不给予流传，明话听着直白

---

• Q1：追梦啊，我看有的餐厅他们没有服务员和小工，他们只有厨师，我看他们也能运营下去啊！
• A：一般这种餐厅都是街边小摊，这种运营方式是厨师即当服务员，也当小工。这种餐厅是很难将其做大的，即使有人投资，在只加入厨师的情况收入也不会有很大改观。（项目只有Service层，没有Controller和Dao的分工是没有老板想要用的，其他程序员也不愿意看）

• Q2：追梦啊，我看有的饭店他们是有服务员和厨师的，但是没有小工啊！
• A：吃饭的人多起来，厨师是会累死的，顾客也会嫌慢。（用户多起来后，项目所占用服务器资源大，服务响应慢，用户使用体验差）

• Q3：追梦啊，即使有的饭店他们配备了服务员、厨师和小工，但是他们出菜的速度还是好慢啊！
• A：后厨面积太小，员工的工作速度慢。（服务器内存小，cpu工作速度慢）

• Q4：追梦啊，人家学校食堂都是先把饭菜做好了等着人家过来点菜就是了啊！
• A：学校食堂这么干主要是由于到饭点，学生居多，需要满足学生在短时间内进食然后做学生自己的事。（像商品秒杀、定点直播等这种有着流量高峰期的项目，可以采用缓存的方式去满足用户需求，比如项目中引入Redis）

• Q5：追梦啊，我写的项目怎么在很多人同时使用的情况下数据会出错啊！
• A：咱们厨师也不会影分身啊不是吗？（在多线程下，数据的访问远比我们想象的复杂，线程1可能调用线程2拿到的数据，即线程不安全，详情可以问度娘程序的运行与进程）