XMLHTTP和浏览器端表现技术的讨论

更期待你发起一个开源项目，来发展这个框架，我们会提供尽可能的帮助的，例如CVS服务器，项目讨论，项目发布等等。

大家对这种框架是怎么看的：
xml定义简单的业务、view,然后通过引擎生成view。
这样做的好处，是实施的时候，需要增加字段，只需要改一下数据库，然后修改
xml。这样做的好处是不许要重起服务器，可以比较快速简单的实现用户的配置。
（如董事长、经理、业务员对同一张表想看的内容不一样，只需要给他们配置不懂的xml文件，如果在xml增加过滤条件，如a班只能看到a班的数据，b班只能看到b班的数据）.
不过，要做好这样的框架，是很难的。

to dlee:

我看MVC不是很绝对，难得你有兴趣我想在这随便聊一聊，我觉得MVC从提出到现在其实已经经过好几个形态的变化。第一个形态是经典的三角形结构，适用于C/S结构，因为MODEL和VIEW之间有数据管道，通信很方便。

应用到B/S结构后事实上MVC中的M和C的关系已经断开了，演变成了一种三点的链状结构，这时C还充当了M和V的数据管道。我更愿意将之称为双键结构，这种结构虽然是为了适应WEB的非连接环境而迫不得已形成的，但是却演变成更加灵活的模式。

应用了XMLHTTP的WEB应用程序可以看作将原来的V用一个MVC来实现，也就是MVC在V这个部分中的一个递归应用。这时候应用程序级的CONTROLLER充当了View－MVC中的MODEL，从CONTROLLER以下所有的细节与VIEW无关。这样是不是从结构上保证了层次结构的清晰和扩展性的改善呢。因此XMLHTTP应用不是一个局部方法的改良，而是带来了应用程序结构的根本改变。因此它比STRUTS、WEBWORK等框架的贡献更大就不奇怪了。

我在V中的做法是定义一个requestXmlDom和一个responseXmlDom，分别用于从js中封装消息到servlet和从servlet返回结果到js，可以将V和C之间可能发生的所有类型的交互内容都抽象出来封装在这两个XMLDOM之中。因此js是一个控制器，它连着HTMLDOM，servlet同样是一个控制器,它连着DTO，两个控制器之间通过两个XMLDOM的传递一来一回地通信，
清清爽爽。想一想JSP中的scriptlet和taglib，有没有感觉到差别呢？

说了就不怕挨骂，欢迎大家开火，真的！

但是，还需要考虑到，如果用当前熟练的技术实现用户的需要比较困难的时候，
则可以使用其它技术。
就象js也能构造出类似于dephi的界面，但是相当困难，我宁愿用swing。

要钱啊，而且，可能不能满足要求，但又不能改进。

这个观点确实是一个非常有启发性的想法。我一直感觉采用 XMLHTTP 有很大的意义，改变了整个应用的设计方式，但是没有想到有这么大的意义。
以前我在学习了《J2EE 设计模式》（表示层的模式似乎就是在阐述 Struts 的设计思想）以后，已经理解了 MVC 作用和优点，但是我仍然希望找到一种更简单的替代方案，等到使用了 XMLHTTP 后发现就是我要找的东西。现在清晰的分层已经不一定需要依赖 MVC 了，而且还可以充分利用好浏览器端 DHTML 的能力。当然我想 MVC 在这种开发方式下仍然可以得到很好的应用，今天看到你的发言，发现其实就是我在找的另外的一个东西。

我想一种架构提高开发效率的关键还是它能够使得页面中的数据与数据库中的数据之间的流动达到一种无缝的、不需要很多干涉的顺畅效果（页面中的数据和数据库中的数据的交换、更新实现自动化）。你们的开发效率这样高我想还是因为你们做到了这一点而不完全是因为采用了 MVC。不知道我的理解是否正确，希望指正。

很高兴就这个问题与大家探讨，我感觉MVC的出现说到底就是为了解决一个分层问题，分层也是工程上解决复杂问题并将之简单化的最朴素的方法。而MVC其实就是实现一个基本分层的通用软件结构。可以看出我前面提出的MVC的几种应用形态的演变其实就是为了实现不同技术条件下的软件层次结构。我之所以提出递归地应用MVC就是因为我们将应用程序进行了递归的层次划分。开发人员一直将MVC作为应用程序开发框架，这其实是一种习惯的延续，其意义在于实现应用程序的层次。MVC可以实现应用程序的层次，为什么就不能实现层次内的层次呢，这就是我在开发这套框架之前给自己提出的问题。

To jasonhsu:

看到你的描述，和dlee上面引用曹晓钢blog中的话，我想你的设计思路和曹的思路应该是一样的。就是Javascript和Servlet两端都绑定对象，之间用XML来同步，中间Quake Wang提到可以使用xwork来interceptor来在Servlet端实现透明的 PO <-> XML转换，这和我前面想得一样，Javascript端也有曹提到的A JavaScript XmlSerializer来转换，因此这种方式理论上到是可行的，如果整合的好，可能很不错。值得去摸索一下。我到不觉得曹提到得对象关系怎么进行双向映射处理的问题会比较麻烦，我觉得这些关系可以放在Servlet端进行转换，把Javascript扁平的对象关系转换为Java立体的对象关系，但是仍然有3个问题我没有考虑清楚：

1、性能问题
我会比较担心Javascript每次交互都要承担大量的XML DOM构造，解析等等，在大数据量下面的出问题，即使不是很大的数据量，在多开一些窗口操作的情况下，也会把机器拖得很惨。

2、Javascript开发的问题
事实上在当前Javascript没有一个非常有效的调试和开发环境，在基于XMLHTTP的方案中，用户和浏览器交互，主要不再通过页面跳转进行，而是通过点击页面中的元素，触发页面元素绑定的事件处理的Javascript代码，由Javascript来驱动浏览器端和Servlet之间进行数据交互。那么不可避免的意味着非常复杂的，大量的Javascript的编程，同时页面代码的维护难度也极大的提高。

过去我有个同事Javascript功力也很高，他可以写出来各种交互能力极强的页面，构造的那些非常复杂的Javascript代码和函数，他在页面里面用层做出来的窗口就像一个桌面程序那样，可以以假乱真了，但是到最后只有他自己一个人能够维护，其他人都改不了。

3、把Javascript对象和Java对象进行映射和转换，是否会增加页面和后台系统之间的耦合性

实际上Struts的FormBean就做了这样一个不好的表率，把页面数据搞成对象，和PO进行混用。我担心Javascript对象绑定也会出现类似的问题。

不过总体来说，我还是期待能够出现一个这样的开源的框架，不成熟，不完善到是可以慢慢来。

说句题外话，XMLHTTP是MS放进IE里面的ActiveX，但是MS自己显然放弃了用XMLHTTP去构造下一代浏览器交互技术，这应该不是没有深层次原因的。事实上在当前的这些浏览器技术中，都可以算做螺鲺壳里做道场，捉肩见肘阿。浏览器本身的功能不进行大幅度扩充，这些问题终归得不到彻底的解决，因此我个人宁愿先用HTML，等到XAML/XUL出来以后再切换。

robbin，XAML 我不大清楚，XUL 几年以前就可以用了啊。其实 XUL 还是严重依赖 JavaScript 的，所以 JavaScript 的生命力是非常顽强的，这是以前我在 linuxtea 预测 JavaScript 10 年以后仍然会健在的原因。即使是 XAML 不过就是 XML 词汇表的一种，要想达到很好的交互，仍然需要依赖某种类似于 JavaScript 的脚本语言。你可以看一下上次我给你的书里面的：
xul - oreilly - Creating_Applications_with_Mozilla_ch02_Getting_Started.pdf
这本，里面使用了大量的 JavaScript。

其实 JavaScript 真的是很难绕过的，甚至还有一个狂热分子写过一本书：
《How to Do Everything with JavaScript》
McGraw.Hill.How.to.Do.Everything.with.JavaScript.pdf
所以你们培养一些 JavaScript 高手还是非常有必要的。

to robbin：
首先请你原谅我上面的冒昧，在HIBERNATE方面我一直认为你是我的老师，就象在XMLHTTP上DLEE是我的老师一样，你们都在不久前回答过我非常非常初级的问题。

关于你提的几个问题，我试着解释一下：


我使用时每次JS与Servlet的交互内容都非常少，每次交互只完成很少的功能，根据界面的功能决定，这种交互也许使用得很频繁，界面也许会在不刷新的情况下与服务器进行几十次交互。我不知道这是不是最优的设计方案，我从我的观察来看，客户端的处理能力远不是问题，至少我还没遇到过这个困扰。



我写JS就是用的EDITPLUS，一开始可能有点慢，但从第二个应用开始，大段代码都可以COPY And PASTE了，其实我是将文件另存为，然后修改属性名称。我从写第一行JS代码开始到现在不到两个月时间，看的书也是DLEE发贴推荐了犀牛书后才买的。现在我感觉到摆脱了scriptlet和tag后页面的开发原来可以这么自由。JS编程不是问题，只要你愿意去掌握它。




可以这么说，你会发现这种耦合彻底地不存在了，我开发时是这么做的，先完全按照自己的设计做页面和JS，JS中只对requestXmlDom编程，其他的都不管。然后按系统分析做PDO，数据表，Mapping文件，完全不管这些在页面上怎么显示，然后数据访问功能作出DTO来，最后做Servlet将数据和指令（对象的消息）对接起来。PDO到servlet为止，绝不上传。所以应该说你的担心是没有必要的。



我的框架暂时只支持JS＋CSS＋HTML这一种显示层方案，但并不表现只能支持这一种，任何可以浏览器上运行的可以解析和构造XMLDOM对象的技术都可以拿来装配到应用程序中替代掉JS和HTML，我也很关心FLASH和ACTION　SCRIPT，我想信我下一个要去掌握的技术就是它了。但到目前为止只要XMLHTTP还可用我是不会再回过头去用STRUTS和WEBWORK了，更不会去学习我还不会的TAPESTRY或是别的什么。