精巧的设计使DWR很容易被java开发人员接受;对传统web程序的无侵害性让它被引入更多的项目。与服务器端通信,DWR很有代表性,并很好的隐藏的xmlhttp对象,也基本可以满足我们要求。如果我们想抛弃传统的webwork/spring mvc等MVC框架,全部数据由DWR来实现的话,也有一定风险。没办法,只能挖掘DWR深层次的应用了。
一、业务层设计
为了讨好传统的,用户量惊人的传统web应用。可能更准确的说是webwork/jsf为了和火热的AJAX套上关系,主动和dwr联系。dwr可以与Struts/JSF/PageFlow....集成。webwork最先干这个事,效果不好,用户根本不满足那一点点ajax应用。我认为与DWR的服务器端业务层最合适的是spring.也就是DWR的creator最好的是spring IOC框架.
前段时间考虑,想在service层前面再有一外观层,因为dwr/ajax在浏览器端可能有很多细粒度的方法,以防破坏service层OO特性.(太教条了). 我们设计service层时,完全可以考虑,我们正在为DWR设计服务层,该注意的都应该注意.例如方法不能重载,不能用javascript关键字delete......
设计要点:
细粒度方法,粒度划分由浏览器业务决定.void updateName(id,name); void updateUser(user);???
方法的参数能用基本类型就用基本类型,可能性能会好点???
避免方法重载
关键字
//todo
二、关于PO/VO....
如果你用hibernate,如果把PO让dwr的HibernateBeanConverter处理,可以看http://getahead.ltd.uk/dwr/server/hibernate .
好象也有问题,尤其是hibernate3属性的lazyload.
- User.getRoles();
- roles.getUsers();
- logic.getUser();
- logic.getUserList();
- logic.getRolesList();
- ........
User.getRoles(); roles.getUsers(); logic.getUser(); logic.getUserList(); logic.getRolesList(); ........
好象VO/DTO又有出头之日了.
另外还有一个问题.
- logic.java
- User logic.find(int id);
- logic.save(User user);
- action.java
- User user=logic.find(id);
- user.setName("");
- .....
- ....
- logic.save(user);
logic.java User logic.find(int id); logic.save(User user); action.java User user=logic.find(id); user.setName(""); ..... .... logic.save(user);
如果在ajax应用中,我相信会有logic.updateProper();这些细粒度方法,如果还象以前那样,那AJAX还有什么意思.
我现在意见是AJAX为主的应用中放弃hibernate,用spring template,不考虑OO.
毕竟不是所有的应用都适合AJAX为主.
- ajax portal
- http://my.msn.com
- Window对象
- 改变它的位置
- 填加连接
- ......
- 这些细粒度方法.OO不见得有多合适.
ajax portal http://my.msn.com Window对象 改变它的位置 填加连接 ...... 这些细粒度方法.OO不见得有多合适.
三、DWR服务器端扩展
1 、htmlConverter
DWR最让人称道的是java方法可以由javascript调用,并把java对象和"json"互换.如果一个特点特别亮的话,那它肯定会有更大的不足.
ajax可能传递 xml/json/html片段等.这里我觉得json基本可以替代xml,但html片段,dwr几乎没有支持,虽然可以由json包含html片段,但注意,这个html有java生成.html片段我任何还是很有必要的.
如何生成这些html?由java实现?freemarker?htmlConverter?如何简单配置?值得考虑一下!
2、如果简化converter
dwr提供的converter功能已经很不错了,但是扩展.编写自己类型的converter还是很麻烦.
现在服务器端生成javascript也挺热闹,虽然偶不是很感兴趣,但如果dwr能把converter弄简单一些,包括配置,扩展,所见既所得.那就完美了.
另外对于java反射感觉不爽,如果在正式运行环境下,把具体对象bean/object converter重写一下也是方便的.
四、客户端开发
通过服务器生成javascript,与service函数对应.方便确实方便,但这也成了众多人的批判点.其实这些js不下载,dwr也可以运行的很好.
其实dwr的这个封装没有必要,限制的dwr的开发.比如偶想在客户端做个cache,nnd,函数类型,不爽.编写无聊的,可能层次很深的callback函数.让代码很乱.
另外dwr能称为ajax framework真有些牵强,如果不是j2ee程序员喜欢赶时髦,唉,这帮不知疲倦的人啊.
主要是客户端代码太弱,还须努力.
这部分我已经做了点点工作,过几天show一下.