基于模型的展示层开发方法陈大峰终Word文档格式.docx

基于模型的展示层开发方法陈大峰终Word文档格式.docx

《基于模型的展示层开发方法陈大峰终Word文档格式.docx》由会员分享，可在线阅读，更多相关《基于模型的展示层开发方法陈大峰终Word文档格式.docx（5页珍藏版）》请在冰豆网上搜索。

很多时候做项目，我们会发现有些地方可以不断积累，不断找到好的方案出来。

今天分享一下模型展示层开发方法。

我们现在开发的时候让人觉得心里最没底的，很多是展示层的东西。

我自己有一个业余爱好，去研究各种各样的框架，不管是JAVA还是PHP也好，我之前也用过很多JAVA框架，PHP也用过。

我开始用PHP的时候，感觉跟我们搞JAVA的很不一样，但是确实有很多值得学习和吸取的地方，慢慢有一些想法在里面。

分析下来，现有的开发方法里面有两个突出问题，导致展示层开发会比较费力。

第一点是Context，我们写模板的时候，会有一个Context从头传到尾，就是所谓的模板上下文，这是一个造成问题的原因。

第二个问题就是Control，这是一个比较精巧的设计，如果用的好，这是非常好的机制。

但是如果用的不好就会像用榔头切菜一样。

有的是滥用导致的。

首先看一下ContextHell，当你接手一个新的应用时，特别是展示层比较复杂的时候，你是怎样知道这个Context里面有哪些变量，哪些VO可以展示的。

是的，总结修来，就是跟踪、Debug，或者输出一些日志。

我之前做offerdetal应用，把之前的代码全部扫了一遍，context里面展开来有一千多个属性，存在不同的MAP或者VO里面。

如果我们是写逻辑层的，提供这样一个API给UED开发前端的话，他们拿到之后会很崩溃，因为这里首先根本不知道有这么多东西，就算知道有这么多东西，也不知道用哪一个。

在这里我分析了一下，为什么需要用这么多VO。

之前有邮件讨论过，说老是写一些mapper，在VO和DO之间做拷贝，代码很长看起来又没有什么技术含量，可是又不得不做这个事情。

这里有一些深层次原因，不是说我们不懂设计模式，我们只能这样做。

为什么需要做VO，其实有一个一级缓存的问题。

不知道有没有用过Hap的OIM框架的，有一个一级缓存、二级缓存概念，有没有同学解释一下一级缓存吗？

一级缓存一般在一个request期间使用。

这个红的表示代码执行流程，这是一个request，从这里开始，到那里结束，你去想象执行是这样的，这是AO，这里是模板。

（图6）

这里面是Control，在这里面假设从最开始入口的地方拿到一条交易记录，如果我在后面这个地方还要展示交易记录信息，那需不需要再到数据库拿一次？

不需要了。

一个request里面，即使从这个地方拿到这条交易记录，这个时候版本是1，可能到后面这个地方的时候变成2了，但是我还是会用1的这条记录，因为不需要精确到毫秒级，这个东西我即使要用多次，也不会每次去数据库拿。

包括对记录进行修改的情况，一个request里面也只会去取一次。

要传递这些数据，避免重复加载，这个地方就用到一级缓存。

这是VO的一个场景，需求越来越多的时候，有越来越多的中间结果要保证下来，让后面人使用。

第二个需要使用VO的原因，我把它称之为封装展示逻辑，这个展示逻辑比如像价格，你告诉用户价格是多少，用户脑子里价格是一个整体，比如说一元每斤，这里有一个1，有一个元，有一个斤，脑子里的信息是整体的，但是在访问数据库里面的时候，1是一个字段，元是一个字段，斤是一个字段，而且元可能不一定在一个表里面，可能在另外一个表里面，这是底层数据的结果跟用户看到的信息不一样的，这是我们需要封装起来。

对于一些封装逻辑，要在底层用JAVA写一个工具类封装起来。

放在里面效果是很好，模板的原代码比较干净，问题是这个VO很难重用，因为每一个页面我们看到内容都是不一样的，所以不同界面所需要的VO不一样，就算你重用的话，心里也没底，也许我会用错，或者别人改了他的VO会把我的文字页面改错，所以会尽量避免这种重用。

它的结果就是这样的，囚徒困境，不能达到一个很好的效果，就算是有一个很好的VO出来，也不敢重用。

最好是局部优化，确保我写上去的代码不会有故障。

所以你经常看到这个VO相差不是很多，但确实自己要写一个，但是从全局来看，VO越来越多。

你针对自己的VO写了一个工具类，后面一个人看到这个东西好用，他想拿到用的时候，他的VO和你的VO接口不一样，要转一下，转换代码会越来越多，这是展示层里面的代码比较罗嗦的原因。

接下来我们再看一下Control的问题，Control是把页面切分的一个方式，切分成不同小片，每个片就是一个Control，这里有两个问题，第一个，怎么找出某一个页面模块，你怎么找到对应这个模块的Control文件的？

到底有没有尝试过想通过某一种模型，把Control之间的关系建立和平，有没有同学尝试过，你为了方便维护模板，这个图一眼知道这个是什么文件？

同学：

模板整理做过的，在Excel里面，效率很高。

我最开始也是这样搞的，开始要画图，画着画着不对劲了，太复杂，看不清楚了。

然后用EXCEL，但是还不是很直观，后面想到一个很好的方法，给大家秀一下。

人的脑子里面记忆力，同时能够组织的东西只有七个，你同时能够把七个文件想清楚就不错了，你如果慢慢整的话，不知道整到什么时候，所以我用了这样一个工具DOT，自动生成图像的工具。

我写一个程序，把模板包含关系、依赖关系扫描出来，然后输入到DOT里面去，它用了一个算法把图像调整为最简洁的布局，大家看看这张图，这是最“简洁”的效果。

出现这种情况的原因是什么呢，我相信每一个做应用的同学也希望代码写的很漂亮，没有人愿意搞出这么复杂的东西出来，为什么有这种Control，有两个原因，第一个原因，做懒加载，我们有很多这种流程逻辑，可能有一些路径不用访问某一些数据，我就可以利用Control这么一个机制。

像这一块有的要显示，有的不要显示，我就可以用这么一个Control，在Control访问数据库，这还是一个很聪明的方案。

第二个，这跟VO要解决的类似的，就是封装展示逻辑，我们可以放到VO里面，有的通过Control去实现，比如抽出来很多小的Control，问题是这样抽出来之后，有一个很头痛的问题，因为嵌套的路径非常深，如果想在最深的这个地方增加一个参数，得把整个路径上的模板都要改一遍才能传进去。

不管怎么样，我们还是有很多同学用这个办法，用Control去实现展示逻辑封装。

这样去使用Control的问题是什么，这个模板切分的方式和页面上眼睛看到的豆腐快切分方式好像完全对不上号的，因为对不上号，我们发现改东西就很别扭，这么一搞之后，可能磨半天才能把一个问题解决掉。

其实我们很多开发人员、维护人员不是不想优化这个情况，而是他找不到一个最好的办法，这是我想出来的两个问题，不知道有同学还有其他想法，我们展示层自己有一些想法，有一些感觉，有去思考或者说总结的？

有没有同学做过展示方面的重构？

说一下基于模型开发展示层的方式。

这个方式应该说自己已经用了三四年了，最近一次使用是在VIP这个项目里面，大家知道阿里巴巴搞了一个商城，开始想做一个实验性的网站，很快两个星期做出来了，我非常顶这个项目，就说我一起去做，当时我做后台，把VIP商城一些类目、Offer这些东西建立一个模型，提供一个接口给前台，我们有四个同学开发前台页面，基本上模板里面不需要写像URL这样的，不需要太多做，模型API给出来之后，按照Demo去实现模板就好了，所以当时做得很快。

这个办法还是有一些有意思的地方可以跟大家分享，首先我们来看什么是模型，模型是对我们现实世界当中一个实体的描述，比如说有类目，有Offer。

OfferDO也是描述Offer的，但是在我们的概念里面模型实体和DO区别是什么，它是一个完整描述，就是这个模型是全的，它包括属性、联系等，有一些属性不是从Offer表里面拿到的，比如说offer还剩下多少库存，曾经有过多少笔交易，还有比如offer的ETC价格，要跑到另外一个接口里查一下才能拿到数据。

如果我们去基于模型做，我们会把整个都放在Offer里面来，而不是拿offerID跑到外面查。

和VO的区别也是一样的，一个offer在不同页面展示，VO是不一样的，有的是要展示十个Offer的三个字段，有的是展示一个offer的一百个字段，这就有很多不一样的VO，而我们这里实体只有一个。

另外一个是它的联系，像我们现在按照DO方式拿一个Offer的member的话，我要拿memberDAO去查一下。

如果是实体的话，可以直接从offer实体得到它的member实体，这个看起来区别也不大，多写一行代码。

但是这里它的影响对展示层和动态友好程度是不一样的。

这个好像是说我们跟香港人说话的时候，他可能听得懂普通话，但是他说普通话很别扭，如果我用粤语跟他交流，能够交流的非常痛快。

还有的人英语说的不错，但是出国，他很难交流，因为他沟通起来，总是不是那么到位。

这个也是一样的，如果像这种情况，比如动态语言，我用实体一行代码就可以遍历很多东西。

而在这边，不光自己要一行行写，还有一个很重要的就是我必须把这个memberDAO注进去。

而像模板这种环境里面，不可能去拿到这么多DAO。

这个变化虽然看起来很简单，但还是比较深远影响的，这个模型和我们现在的做法方式有什么不同，我总结是三个问题，第一个就是我们VO从头穿到尾，第二个是懒加载，就是写一个Control，然后显示那一块的时候，就可以加载数据，第三个需求是展示数据，有的时候用VO，有的时候用Control去做事情。

现在是这样做的，这个是Context，封装是Control加VO，如果基于模型来做，对应的方法是不一样的，我会把前面两个问题归结到这个domain模型里面去，最后一个问题是放在View模型里面来，用这样的方式解决问题。

整个想法很简单，我们先假设有一个最全的数据模型，这个数据模型把所有相关的数据都包括进来，不管是来自数据仓库还是什么地方，这样在模型里面你想要就能拿到，这样就很爽。

在实际实现当中，不可能一开始把所有数据七八个表的接口全部调一遍，这里需要一些机制，但是这是后面可以解决的问题。

这个好处是，像我们以前要满足一个业务场景，要做五个页面，要写五个VO，有了这个模型以后，一个模型就可以满足我绝大部分需求了，而且这个模型如果以后加一个字段的话，这个模型局部添一下就可以了。

如果像以前过程式的AO、VO写下来的话，那要去找最合适的一个地方插进去，确保我不会在不该加载的时候加载。

实现的话很简单，把握两个，一个是实现一级缓存，第二个把这个懒加载实现，这样就出来了。

这里面的实现方式，自动ORM的话，封装JDBCConnnection，自动将DO变成Entity。

另外一个是手动ORM，这样想就是封装DO/Servico，手动将DO变成Entity，这样模型就出来了。

View模型的话，像那种信息本来在我们数据库DO里面，想象我们将80%的业务场景中所需要的展示数据，全部预先计算出来，并放到一个大而全的统一数据结构。

这样80%的业务需求只要用Getter方法遍历这个数据结构就可以了，无需任何额外开发。

它的好处是什么？

模型包含所有展示数据，避免了封装展示逻辑引起ControlHell。

模板中不用做任何展示逻辑的计算，高度可维护。

而在ViewModel的实现里面，将领域模板中的方法和字段暴露为对模板友好的API。

这里有一个实现案例，wordpress中API以及laputa中的Tag。

DomainModelVSViewModel，View模型中的数据源自Domain模型。

80%直接取自Domain模型；

20%经过一些计算和拼装。

二者的不同之处：

Domain描述的是系统执行业务逻辑所需的“数据”，而View描述的是用户能理解和输入的“信息”。

例如：

“面包屑”是由“展示类目”生成的，但二者的复杂度相差极大。

利弊分析

基于模型开发展示层的好处：

提高开发效率

前后台逻辑分离非常干净，前后台开发人员可以高效并行工作，避免“UED写Demo、开发整合到模板”的低效模式

前台模板的编写非常简单，只要熟悉ViewModel的API就可以了；

维护也非常简单，避免ContextHell和ControlHell

降低维护成本

业务变化对应用的影响被降低到最小，绝大部分变化只要局部调整Model就能将其影响吸收掉，而无需调整业务代码

存在的问题：

与现有的AO-BO-DAO基于过程的架构模式有较大不同，无法在已有系统上实施。

对开发人员有一定的设计能力的要求（将需求抽象为模型变化，而不是到处修改业务代码）。