[基于模型的展示层开发方法——陈大峰终.docxVIP

陈大峰： 淘宝商城昨天搞11.11促销活动，里面有一个投票，淘宝商城搞活动，大家最想买什么，70%选择Iphone4。我看微博讨论，说苹果最大的专营店，外面排队排的很长，除了排队，还要登记，过几天Iphone才能到。有一个老太太在那里看，看到那么多人在那里买手机，她想这个手机是不是很便宜，为什么买的人这么多。 我比较感慨，现在的人不是说没有钱，或者说没有梦想买好的东西。他们排队去买这种产品，这样的事情很少。有的人就能做出非常完美的产品出来，这是让我对乔布斯敬佩和崇拜的地方。 我们在技术方面永远追求完美，有一天才会在技术上达到一定境界。很多时候做项目，我们会发现有些地方可以不断积累，不断找到好的方案出来。 今天分享一下模型展示层开发方法。我们现在开发的时候让人觉得心里最没底的，很多是展示层的东西。 我自己有一个业余爱好，去研究各种各样的框架，不管是JAVA还是PHP也好，我之前也用过很多JAVA框架，PHP也用过。我开始用PHP的时候，感觉跟我们搞JAVA的很不一样，但是确实有很多值得学习和吸取的地方，慢慢有一些想法在里面。 分析下来，现有的开发方法里面有两个突出问题，导致展示层开发会比较费力。 第一点是Context ，我们写模板的时候，会有一个Context从头传到尾，就是所谓的模板上下文，这是一个造成问题的原因。 第二个问题就是Control，这是一个比较精巧的设计，如果用的好，这是非常好的机制。但是如果用的不好就会像用榔头切菜一样。有的是滥用导致的。 首先看一下Context Hell，当你接手一个新的应用时，特别是展示层比较复杂的时候，你是怎样知道这个Context里面有哪些变量，哪些VO可以展示的。是的，总结修来，就是跟踪、Debug，或者输出一些日志。我之前做offer detal应用，把之前的代码全部扫了一遍，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接口不一样，要转一下，转换代码会越来越多，这是展示层里面的代码比较罗嗦的