overlook. [补] [Permalink]
Wed May 26 13:00:24 CST 2004
Category [working on downwap.]
大方向上是确定的，框架就是标准的MVC。简单明了是第一阶段目标，refactoring将会贯穿始终。对于所有的数据访问类写unittest。就算不极限至少也争取快捷一点。
基本的数据访问字符处理什么的，就用自己几年前写的那个类库吧。毕竟用的时间比较长。虽然不够新潮，不过该有的都有。没有的就扩展加上。
前台。。开始时候有考虑struts，后来想想，对于wap的wml版，用struts有点过了。benefits似乎远远弥补不了drawbacks。干脆就分离wml版和html版的整个前台算了。wml版就力求简单，delicate的东西以后作html版时候再说。
后台呢？能复用当然最好了。将来还能提供soap调用什么的就更完美了，wahaha。。流口水中。。。。问题是——如何实现比较好呢？如何和前台接口呢？选择多多阿。用传统的DTO么？想着一堆堆的字段映射啦，表间关系啦，就头疼。我这么懒的人，做这种繁琐的事情，简直是~~ 同样是体力劳动，不如去拉架子车了。 
一不留神想到了XSL。XSL是个好东西，只要提供原始XML数据，就可以转换成各种形式文档。wml，html，或者其他格式的xml。。为所欲为。而且以前没怎么用过，做起来积极性也高一点点。就他了。
这样不错。。后边就轻量级了。只要把数据封装成简单的xml，就算完成任务了。呵呵。。缺点？当然有。1。弱类型。2。数据库映射还得维护（这个实在不想搞 
）。还有就是不能利用getter setter本身的便利（比如在struts中）。暂时想到这些。肯定还有不少。不过，“轻量级”/“扩展性”这两个优点的确诱人。做做看吧，见到的这方面实例不多，自己走一遍，好处还是不少的。
还有要考虑的。是直接返回客户端xml+xsl stylesheet，还是服务器上转换好，再返回client呢？哈！想什么呢，只能是后者阿！除了十几几十MB的browser，谁没事带个xsl解析器的啊。给手机一个xml让他找到xsl然后transform。。呵呵。至少在这个季度还是神化。我的手机能显示gif，我都谢谢他了。xslt看来是唯一的选择——没有选择其实也是种幸福哦。
总结一下：
目的是多种客户端。
Posted by: miles
Comments [0] |
