基于模型的展示开发方法.pptVIP

基于模型开发展示层的好处： 提高开发效率 前后台逻辑分离非常干净，前后台开发人员可以高效并行工作，避免“UED写Demo、开发整合到模板”的低效模式 前台模板的编写非常简单，只要熟悉View Model的API就可以了；维护也非常简单，避免Context Hell和Control Hell 降低维护成本 业务变化对应用的影响被降低到最小，绝大部分变化只要局部调整Model就能将其影响吸收掉，而无需调整业务代码 存在的问题： 与现有的AO-BO-DAO基于过程的架构模式有较大不同，无法在已有系统上实施 对开发人员有一定的设计能力的要求（将需求抽象为模型变化，而不是到处修改业务代码） * * * 陈大峰 2010/11/11 展示层开发的问题 Context Hell 及其原因 Control Hell 及其原因 基于模型开发展示层 Domain Model View Model 总结 应用系统维护，模板难度居首 感觉像个黑洞 –不可读、不清晰、不灵活 根源在哪里？ Template Context – 数据结构不可读、不清晰、不灵活 Template Control – 页面结构不可读、不清晰、不灵活 怎样知道Context中有哪些变量和VO（数据对象）？ 源码跟踪，找出detail screen调用的所有AO/BO/Control中的map.put和context.put 或者用Debugger监控Detail页面的所有分支，将Context中的内容dump出来分析 Offer Detail的Context中有多少变量和VO？ 60+个数据对象（VO、Model、Map） 1300+个属性 80%没有使用，或者是冗余属性 还不算URIBroker和Pull Tool！ 为什么需要用VO? 充当一级缓存：在超长的控制流中收集/传递数据，避免重复加载 在screen、control、AO、BO、Service、vm中都会用到某些业务参数、产生或使用某些中间结果；这些数据只能封装到VO中传递（有的VO被各层使用） 数据流完全隐含在控制流之中；不同场景需要收集和传递的数据字段不同 VM, Pull Tool Screen, Control, Util AO, BO, Service control-flow data request 开始 request 结束 为什么需要用VO? 封装展示逻辑：将底层的字段数据变成用户可理解的信息 避免在模板中写复杂的pull tool调用、字符串计算、uri 拼装等（特别是这些数据在多个地方出现时） 为什么需要那么多VO? 难以重用（不同页面要传递和收集的数据字段各不相同） 重用风险太大（不知道VO被哪些场景/层使用/修改） 学习成本太高（不知道Context里有哪些VO） 对于维护人员来说： 最佳策略是局部优化 -- 自己写VO、自己put到Context中 对于系统全局来说： VO越来越多 Mapper越来越多 冗余越来越大 维护越来越吃力 怎样找出对应某个页面模块的Control？ 从页面中找出关键字，全文搜索模板文件 复杂页面的模板切分和页面结构几乎没有对应关系 怎样知道Control的嵌套组成结构？ 在Control中插入div border=1，刷新页面后观察 复杂页面的嵌套结构复杂度直逼人脑认知能力的极限 为什么需要与页面模块不匹配的Control? 用Control来实现展示驱动的数据加载（懒加载） 用Control来封装可重用的展示数据（对用户有意义的信息） 例如：用户看到的“产品零售价”信息实际上由4个底层数据：零售价, 单位, 是否ETC, 货币单位组装而成 模板切分与页面结构失配 大量“封装”展示片段的Control，打断阅读思路和HTML结构 嵌套极深、极复杂的Control结构，超出开发人员的把握能力 与页面模块结构不匹配的Control，导致应对需求变化非常困难 模型是对现实世界中的业务实体的描述 描述的内容包括属性、联系、约束、流程等 实体与DO、VO的区别： 同一个实体中的属性可能来自于多张表，每张表对应一个DO 同一个实体可能有多种展示方式，每种展示方式对应一个VO 实体不仅描述属性，还描述联系。即从一个实体可以直接遍历到与其联系的其他实体 实体： MemberEntity memberEntity = offerEntity.getMember(); DO:  String memberId = offerDO.getMemberId(); MemberDO memberDO = memberDAO.getMemberById(memberId); 一级缓存 收集和传递参数及中间结