Java-029-MVC架构

Web MVC架构

MVC架构

为什么需要MVC架构

回顾一下 Web电子商务系统

Web电子商城主要逻辑模块

API

• 处理HTTP请求, 请求校验
• 解析和转换请求内容
• 调用下层处理逻辑
• 把处理结果转换成面向用户的结果
• 构造HTTP响应和返回

数据访问

• 数据ORM
• 实体对象
• 数据访问模型 (DAO)

业务逻辑

• 用户身份校验
• 产品信息校验
• 创建购物车中的收藏记录
• 产品库存管理
• 订单生成
• 等等等…..

那最粗暴最极端的做法是把所有这些代码逻辑都写在API里!

那很容易出现的问题就是:

• 巨大的方法和类. 比如, 我见过15000行的类和其中5000行的方法
• 逻辑的交叉, 可能会导致代码没法重用
• 代码的重复和不可重用
• 数据流的混乱

那我们最先想到的的是划分模块:

API (Controller) 模块

• 处理HTTP请求, 请求校验
• 解析和转换请求内容
• 调用下层逻辑
• 把内部处理结果转换成面向用户的结果 (View)
• 构造HTTP响应2和返回

数据访问

• 数据ORM
• 实体对象
• 数据访问模型 (DAO)

业务逻辑 (Business) 模块

• 用户身份验证模块
• 产品信息验证
• 构建购物车中的收藏记录
• 产品库存管理
• 订单生成
• 等等等……

其中 API 模块中, 我们看到一块很重要的部分, 就是面向用户的部分, 这部分是API和前端或者用户直接交互的数据的结构, 所以单独抽象成一个模块

交互 (View) 模块

• 请求结构
• 请求和内部Model的转换
• 内部处理结构和面向用户结果的转换
• 面向用户的结果
• 页面, 如果HTTP页面是在后端构造 (JSP或者其他模板系统)

其中什么部分是Web项目中通用和必须的呢?

aView, Controller, Model

MVC架构

分层模型

除了分模块, 我们应该注意到在MVC架构中, 我们还可以有一个分层的结构

View —> Controller —> Business —> Model

这样单线的依赖关系, 可以让代码逻辑更加清晰, 我们可以想象成一个生产线或者流水线, 请求逻辑一层层拆解处理, 流水线上每个模块各司其职, 最后的终点是Model, 再把需要响应的内容, 从Model中提取出来, 再一层层按原来的路线往回传递.

Serverless架构

代码链接