【软考系统架构设计师全链路通关实战】第 38 篇层次式架构设计MVC、MVP 与分层演化本系列定位以软考系统架构设计师高级考试为主线语言无关的架构方法论视角覆盖官方教程全部 20 章考点按「综合知识 → 案例分析 → 论文」三科组织每篇含考点精讲 真题规律 应试技巧 Mermaid 图解。本篇你将学到层次式架构分层架构的原理、优点与固有缺点——案例分析论述题的作答骨架三层架构表现/业务/数据访问到四层架构的演进逻辑MVC 的 Model/View/Controller 职责划分与交互时序MVPPresenter 中介与 MVVM数据绑定的演进动机与三代模式对比大表工厂模式、单例模式、代理模式在分层架构中的落地方式语言无关示例智联云商 v1 单体分层完整实例 层次式架构论文写作框架为第 51 篇论文打底本篇是模块八「八类架构实战」的开篇也是案例分析与论文双热点。考点热力表考点综合知识案例分析论文分层架构优缺点★★ 常考概念★★ 简答常考★★ 论文论证段三层/多层架构职责划分★★★ 高频★★ 补图/设计题★★MVC 结构与交互★★★ 高频概念★★ 时序补图★★MVP/MVVM 对比★★ 近年升温★ 偶现★设计模式在架构中落地★★ 高频结合工厂/单例/代理★★ 代码填空★★ 论文亮点素材层次式架构论文☆☆★★ 高频论文题之一一、层次式架构原理与优缺点层次式架构Layered Architecture是第 22 篇调用返回风格家族中最重要的成员系统按职责划分为若干层次每层只与相邻层交互上层调用下层服务下层不得反向调用上层。OSI 七层模型、操作系统内核分层、数据库管理系统内部结构都是它的经典化身。1.1 优点论述题标准答案五条关注点分离每层职责单一表现只管交互、业务只管规则、数据访问只管存取复杂问题分而治之。可维护性修改被封装在单层内只要接口契约不变其他层不动——这正是第 30 篇「可修改性战术局部化变更」的结构化实现。可复用性每层是对下层功能的抽象同一业务层可同时支撑 Web、App、开放 API 等多种表现层。团队分工与并行开发按层切分工作面接口先行即可并行。层间松耦合、利于替换数据层从关系库换到 NoSQL理论上只动数据访问层。1.2 缺点与优点同频出题必须会写性能损耗请求逐层传递跨层调用带来额外的序列化/转换开销不能「一步直达」。级联修改底层接口变更会沿调用链逐层向上波及层次越多波及面越大。并非所有需求都能干净分层某些横切需求安全、日志、事务天然贯穿所有层强行分层导致重复代码或依赖混乱。层次过多导致过度设计每加一层就加一份间接开销和维护成本。答题技巧案例题问「分层架构有何不足」至少写性能损耗 级联修改两条若题目给的是修改传播场景直接把级联修改作为核心答案展开。表现层用户界面与交互业务逻辑层领域规则与流程编排数据访问层持久化与查询封装数据库1.3 三层到四层演进三层架构表现/业务/数据访问是最常考的基线向四层演进有两条典型路线加「通用服务/应用层」在业务层之上拆出「应用层/服务层」负责流程编排与 Facade业务层专注领域规则——为后续第 39 篇 SOA 的服务抽象铺路。加「持久化 ORM 层」在业务与数据访问之间引入对象-关系映射隔离领域模型与表结构。判断层数的原则每层必须有单一明确的抽象职责且能被单独替换。二、MVC 详解职责与时序MVC 把表现层内部再分为三个角色是三层架构中表现层的最经典细化Model模型封装业务数据与状态以及相关的业务逻辑模型不关心谁来展示它。广义上业务层 数据访问层就是后端视角的大 Model。View视图负责数据呈现从模型读取数据渲染界面本身不含业务逻辑。Controller控制器接收用户输入解析请求、调用模型处理、选择返回哪个视图——是「调度员」而非「办事员」。2.1 MVC 交互时序案例补图题模板ViewModelController用户ViewModelController用户1. 发起请求如提交订单2. 调用业务方法 update()/query()3. 返回数据/状态变更4. 选择视图并传递模型数据5. 读取数据观察者机制6. 渲染结果页面两个高频判定点用户请求先进 Controller 而不是 ViewView 可直接从 Model 取数渲染MVC 允许 View 观察 Model但 View 绝不写业务逻辑。补图题把箭头 2 画成「C→V」开头或让 V 承担计算都是典型挖坑点。三、MVP 与 MVVM表现层模式的两代演进MVC 在 Web/富客户端场景暴露的痛点View 与 Model 之间直接耦合箭头 5视图难以单独测试与复用。两代演进都围绕「切断 View 与 Model 的联系」MVPModel-View-Presenter引入Presenter 作为 View 与 Model 之间的唯一中介。View 变成被动的Passive View——只暴露接口如 setText/showError一切数据和刷新由 Presenter 主动推送View 与 Model 完全隔离可对 Presenter 做纯逻辑单元测试。代价是 Presenter 膨胀、接口爆炸一个页面一套 View 接口。MVVMModel-View-ViewModelViewModel 同样隔离 View 与 Model但依赖数据绑定机制View 声明式绑定到 ViewModel 的可观察属性属性变化自动刷新界面消灭了 MVP 中大量手写「set 到 View」的样板代码。代价是绑定机制调试困难、内存泄漏风险绑定未释放。前端框架与桌面声明式 UI 普遍采用此模式。3.1 MVC / MVP / MVVM 对比大表必背维度MVCMVPMVVM中介角色Controller调度Presenter中介推送ViewModel中介绑定View 与 Model 关系允许直接交互View 观察 Model完全隔离完全隔离View 的角色相对主动可观察 Model被动只暴露接口声明式绑定驱动更新机制Controller 选视图 View 取数Presenter 显式调 View 接口数据绑定自动同步可测试性中高Presenter 可脱离 UI 测试高ViewModel 纯逻辑样板代码中多接口手动刷新少绑定代劳依赖方向View→Model 存在Presenter 持有 View 接口View 绑定 ViewModel典型场景传统服务端 Web请求-响应表单复杂的 C/S、Android 早期声明式前端、WPF/Compose演进动机—切断 View-Model 耦合、提升可测试性消灭 Presenter 样板代码记忆钩子MVC 里 View 认识 ModelMVP 里谁也不认识谁Presenter 搬砖MVVM 里绑定牵线数据自动流。四、设计模式在分层架构中的落地设计模式是分层的「砖缝工艺」。综合知识爱考「某模式在架构中的用途」案例爱考代码填空。三个最常与分层架构同框的模式4.1 工厂模式——层间解耦的装配器上层依赖下层的接口而非具体实现具体对象由工厂创建。业务层换一个数据源实现只需改工厂配置业务代码零改动——分层「可替换性」的保证机制。// 数据访问层接口publicinterfaceOrderDao{OrderfindById(Stringid);}publicclassMysqlOrderDaoimplementsOrderDao{/* ... */}publicclassMongoOrderDaoimplementsOrderDao{/* ... */}// 简单工厂业务层只认接口publicclassDaoFactory{publicstaticOrderDaocreateOrderDao(){returnmysql.equals(Config.get(dbType))?newMysqlOrderDao():newMongoOrderDao();}}// 业务层完全不感知具体实现publicclassOrderService{privatefinalOrderDaodaoDaoFactory.createOrderDao();publicOrderquery(Stringid){returndao.findById(id);}}4.2 单例模式——跨层共享受控实例数据库连接池、配置中心、缓存管理器等跨层共享的资源管理器用单例保证全局唯一实例避免重复创建连接池造成资源浪费与状态不一致。publicclassConnectionPool{privatestaticvolatileConnectionPoolinstance;// volatile 防指令重排privateConnectionPool(){/* 初始化连接池 */}// 私有构造堵死外部 newpublicstaticConnectionPoolgetInstance(){if(instancenull)// 双重检查锁synchronized(ConnectionPool.class){if(instancenull)instancenewConnectionPool();}returninstance;}}考点提示私有构造器 静态方法获取实例是判别单例的标志双重检查锁定中 volatile 的作用禁止指令重排是概念题加深点。4.3 代理模式——横切关注点的层间织入分层架构的痛点之一是横切需求事务、日志、权限、懒加载无处安放。代理模式在不改变真实类的前提下把横切逻辑织入调用链业务层调用的是Dao的代理对象代理先开事务/记日志/查权限再委托真实Dao执行。AOP面向切面编程本质就是动态代理的系统化。publicclassTxOrderDaoProxyimplementsOrderDao{privatefinalOrderDaotarget;// 持有真实对象publicTxOrderDaoProxy(OrderDaotarget){this.targettarget;}OverridepublicOrderfindById(Stringid){TransactiontxTxManager.begin();// 前置开启事务横切逻辑try{Orderotarget.findById(id);// 委托真实对象tx.commit();returno;}catch(Exceptione){tx.rollback();// 异常回滚throwe;}}}三者定位一句话工厂管「谁来实现」单例管「只有一份」代理管「调用前后加点料」——分别解决分层架构的可替换性、共享资源与横切关注点三个问题。五、智联云商 v1单体分层完整实例智联云商电商平台第一版采用经典单体三层架构后续第 39~41 篇将沿此演化数据访问层业务逻辑层表现层Web 商城页面管理后台订单服务下单/支付状态机商品服务上下架/库存扣减用户服务注册/登录/权限统一 Dao 层工厂模式创建实现缓存代理代理模式:读穿透MySQL 主从连接池单例模式落地要点映射案例/论文可直接引用的因果链分层带来关注点分离大促期间只扩表现层与应用实例业务规则不动。工厂模式支撑数据源可替换商品检索从 MySQL 切到搜索引擎业务层零修改。代理模式统一事务与缓存订单写操作走事务代理商品读操作走缓存代理。单例连接池控制资源连接数可控不随请求量线性膨胀。遇到的分层之痛论文「遇到的问题」素材促销高峰期层间调用放大延迟性能损耗、一次数据表结构变更波及三个模块的数据访问层级联修改——这两个痛点正是第 39 篇走向 SOA、第 40 篇走向微服务的直接动机。六、层次式架构论文写作框架为第 51 篇打底「论层次架构风格/论 MVC 模式在某项目中的应用」是论文高频题。四段式骨架详细方法论见第 51 篇项目背景约 400 字项目名称与规模、你的角色架构师、项目要解决的核心问题与质量目标强调可维护性/团队协作引出为何选择层次式架构——与第 33 篇 ATAM 的评估结论挂钩更显真实。分层设计约 900 字主体给出分层结构图手绘分层数与各层职责说明层间通信规则仅相邻层交互、接口契约先行重点写表现层 MVC/MVP 的选型理由与模式选型对比说明工厂/单例/代理三个设计模式的落地位置与解决的问题。遇到的问题与解决约 700 字写级联修改或性能损耗的真实案例、分析原因、给出对策引入 Facade 收口、缓存代理、接口版本化体现反思深度——这是拉开分数档位的段落。效果与总结约 500 字可量化的效果如需求平均交付周期缩短、缺陷率下降并客观指出分层架构的局限与后续服务化演进计划呼应第 39 篇。写作红线全文必须围绕自己项目的具体分层展开通篇理论拼凑只背本篇第一节优缺点是论文二类卷的典型死因。本篇小结知识点核心内容分层优点关注点分离、可维护、可复用、并行开发、利于替换分层缺点性能损耗、级联修改、横切需求难安放、过度分层三层/四层表现/业务/数据访问演进加应用层或 ORM 层MVCC 调度、M 数据、V 呈现View 可直接观察 ModelMVPPresenter 唯一中介、View 被动、完全隔离可测试MVVMViewModel 数据绑定消灭样板代码模式落地工厂可替换单例唯一实例代理横切织入论文骨架背景→分层设计→问题与对策→量化效果下篇预告第 39 篇面向服务架构 SOAESB、服务注册与 Web Service 实战SOA 特征与参考架构、ESB 的作用、服务注册发现流程、WSDL/UDDI 实操、SOA 松耦合设计原则以及 SOA 论文写作骨架——从单体分层走向服务化的第一步。如果本篇内容对你有帮助欢迎点赞收藏有任何疑问欢迎在评论区交流。