循证架构

摘自J2EE Development without EJB第二章：

我们在这里就是应该多交流一些这方面的经验。

对于我们公司来说，我们相信把表示层完全前推到浏览器端来做是解决表示层问题的更好途径。
虽然有 n 个人告诉我 JS 开发效率低、容易产生 bug、性能差、难以跨平台，但是我相信下面这个组合：
JavaScript  + XML DOM & XSLT + XMLHTTP + Servlet
是一个简练而实用的组合，这个组合是被我们的大量实践所检验过的。我们现在已经完全不再使用 JSP 和 Form。如果你去另外一个著名的 Java 论坛，坛主大人肯定会告诉你这个不是主流的方案，JSP、JSTL、Struts、MVC 才是业界的主流。

这个组合如果换成：
Flex + XML DOM & XSLT + XMLHTTP + Servlet
开发思路也是一样的。

最新的 Webwork 也准备增加对 XMLHTTP 的支持了。不过我们可以骄傲地说他们落在我们后面了。

上次评论 jsvm 那个朋友说 JS 开发目前还没有什么正路，我想说的是：
路总是人走出来的，习惯于“等、靠、要”的人是永远没有什么正路的。缺乏想象力，眼睛只盯着大厂、主流方案的人同样是没有什么正路的。

这个怎么样？转载：
一直以来我对XUL都不是太感冒。将界面用XML来编写是完全可行的，但是问题是找不到用来解析XUL的客户端。Mozilla有心直接加入对XUL的支持只可惜永远都在期待中；IE好像有自己的想法。所以我一直在观望。

今天在JL上看到了Thinlet，一个采用Applet解析XUL并提供一组漂亮的Widget的客户端解析器，大受启发。仔细的体会了他的几个Demo，感觉很不错。从他的几个ShowCase来看，目前这个东西应用范围还是挺广的，有聊天室的应用，有普通的商业应用。基于LGPL协议使用也不怎么受限制。

这个方案最大的好处在于“JavaScript”这个角色可以换成很多很多别的东西，比如XUL，比如FLASH，比如Curl，比如applet，比如XAML，比如DELPHI。而剩下的东西基本上不会受什么影响。

采用XML而不是VO传输数据还有一个好处在于，如果有Client，那Server不需要重新开发。也就是说使用Dephi代替JS解析XML.

因为这个原因我一直希望连VO都不要了。所有得操作使用XML.任何得操作IO都是XML.IE封装数据成XML.Servlet得到XML,把XML作为参数传给业务逻辑类，返回还是XML。甚至面对DB,也是XML代替PO.直接进数据库。数据库中查询出来也直接就是XML.整个世界清净多了。什么EJB.见鬼去吧，很可惜没有一个O/R Mapping支持得很好。

XML代替PO肯定不是什么好办法，因为PO还有业务逻辑呢。把domain object变成XML又不费事，castor一映射，外面再加个XSLT，齐活。

除了前三位的帖子我还看得懂外，下面的我实在看不太懂了。
   把所有传递的对象全部用XML，有必要么？XML在数据传递方面最大的优势就是解构异构系统，比如UI的展示与后台的实现是完全不同的技术实现。而对于纯粹的同一结构的系统（如java开发的后台业务实现），采用XML作为数据传递，意义何在？（最终不还是要转换成对象么？它顶多就是起了一层类型匹配罢了）。
   另外，PO包含业务逻辑？按照gigix的说法，就是业务逻辑与业务对象是封装在一起咯？（我还是不太懂PO中的业务逻辑是什么？不会CURD也算业务逻辑吧？）那业务逻辑的改变，也就意味着业务对象也需要改变？
   对于Web的UI，我赞成XML、也永远会使用JS，其他的什么flash，flex，我不太清楚，不好评说。

现在网上评论或者介绍的企业应用架构presentation layer几乎都是jsp,js等.
怎么就没有java web start或者applet方面的呢?就因为他们是
rich client就被否定?随着电脑硬件的发展,我觉得rich client并不是很难接受的,但事实上很少见到有这类系统的存在,我知道的只有Oracle的某些ERP用的是applet。
交互性要求高的场合我想象不到jsp,js等是怎样可以实现到的?
简单点比如专案管理,就象ms project那种，jsp能实现吗?
各位能否讨论一下java web start等rich client的应用架构？
hibernate+？？？+applet才能搭建比较好的架构

thinlet真的很不错，用它做Applet就像写HTML一样简单！！当然你得去学习他的tag，不过它应该不算是xul吧，虽然很多tag一样，但应该不兼容的