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

把MSDN上面的XAML文档快速看了一遍，还是没有搞清楚XAML是怎样的一个机制，又是如何整合Desktop 和Web Application的。

似乎大概的意思如下：

如果是本地的Avalon的application，由XAML和数据绑定代码，以及manifest组成，就没有什么可说得了；如果是Web Application，那么XAML和一些component会被下载到本地，类似于Java Web Start这种方式，然后本地的XAML类似于Desktop Application那样运行，需要和服务器交互的话，则通过XML Web Services协议远程调用服务器端的组件。

不知道我理解的是否有错。如果是这种方式的话，客户端和服务器端使用基于HTTP协议的SOAP协议通讯，服务器端自然不限于dotnet。

而XAML丰富表现力对浏览器做了功能扩展和更多的交互功能。而这种交互是通过XAML以及和相应的绑定的C#代码来完成的，而不是通过Javascript。

没想到这个话题如此受关注。其实，robbin的技术直觉我真的很佩服。xmlhttp用的多的公司差不多是这样的：原来用C/S给客户做，后来B/S风行天下，客户嚷着我要b/s，但是对于有些复杂的应用，前端光靠浏览器实在是太弱，所以就HTC,ActiveX,xmlhttp的一套就出来了，而且随着各个项目都用，公司有了一些积累，人员也觉得这种方式挺自然的，我用过struts,ww,和现在的xmlhttp方式，我的结论是，如果你从头来，业务逻辑不是特别复杂，不要用（或局部用xmlhttp），如果你或公司有积累（如dlee），xmlhttp还是能做很多目前web框架不能做的事。我们公司有个小组专门负责这个框架的开发，维护，我们的框架包括后台对报文的处理，以及OR MAP(呵呵，我们公司的一个牛人用delphi中datawindow的概念在前台和后台实现了类似的机制，前台用来显示，处理列表数据，后台用来OR MAP)，这样我们实际上只注重前台业务和后台业务罗基层，其他的持久层，控制层，都由框架来搞定。我们的框架可是获得国家科委40万的资助哦。
robbin一再叫我们拿个例子，为什么拿不出来，因为这个东西必须与其他的语浏览器相关的控件（htc，activex）结合才能有威力，单纯的xml解析是不够的。实际上，前台承担了一部分业务逻辑，并不仅仅是组成xml报文提交，解析后台返回报文了事。
确实是这样的。
所以我们都拿不出例子。确实，js开发调试麻烦，需要人员不断熟悉,熟悉一段时间就好了，毕竟JS是很松散的语言，而且大部分代码都很类似，手熟以后就好了。
我的感觉，前台用M$的smartclient好过现行的任何框架，主要是浏览器承载能力太弱，业务复杂时b/s那个叫人心烦就不说了。
呵呵，乱弹。引用别人的话怎么弄啊，我找不到引用者的名字，原谅。

虽然现在使用XMLHTTP开发感觉很愉快，可是我也有点担心MS会不会使出什么黑招将XMLHTTP灭了，但我很喜欢这种编程方式和程序结构，即使有什么更好的技术可以代替DHTML＋JS＋XMLHTTP我也希望可以保持这种方式和结构。大家对可以保持这种结构的替代技术有没有什么好的建议，我目前了解到的最可能的方案是flash+actionScript+SOAP+WebService,但相比起来这种方案显然比XMLHTTP实现起来更复杂，要遵循更多的规范，同时也有更多的约束。

关于建立一个开源项目的想法，我是这样考虑的，这种开发方式代表了一种轻量级的、快速的、廉价的开方法（个人观点），但它似乎并不适合作成一个应用程序开发框架，而更适合作为一个构件级的开发框架。两者不同这处在于后者对于系统的架构有更高的要求。我目前是在一个企业业务环境中进行这样的开发的，在应用这种框架进行具体业务功能开发之前我实现了很多企业级的基础构件作为对具体业务构件开发的支撑。比如人员与组织管理构件、数据字典构件、RBAC构件等等。如果没有一个通用的、稳定的架构支持，使用这种开发的优势仍然不明显。前面我提到的高速开发事实上是在实现了很多这种基础构件的基础上进行的开发。我在一个大中型制造型企业内部作业务软件开发，我想我的开发方式与软件公司按项目做业务软件系统是有很大不同的。但是企业中做开发确实很累，目前所有的开发工作只有我一个人做，没有一个协作环境，大家更愿意去采购，但长期采购的结果是一大堆五花八门、无法整合的MIS，这种使用效果我在企业中是有切肤之痛的。

很希望与关心企业级应用软件开发的朋友进行交流和合作，同时也希望听听别的企业在这方面有什么好的做法和经验。

直接操纵XML不是OO做法吧，还不如直接胖客户端作RPC，不知道脚本语言支持Remoting否？.Net Remoting多好啊，屏蔽了底层协议和传输格式。服务器端直接用传说中的SOA架构就好了，不用依赖command模式之类的，当然command代替DTO也许还可以吧。

表示层开发为什么一定要 100% OO 呢？能带来多少直接利益呢？有谁能给我一个令人信服的理由吗？

当然不是一定要了，我也不知道信服的理由，说点个人看法吧，呵呵。

比如生成XML消息的时候是喜欢直接拼字符串，还是调用XML API，或者采用自动的映射的机制直接操作对象。在需求比较复杂的情况下，肯定是最后一种较为简单。

这里胖客户端调用层虽然可以算着表现层，但是如果从web应用来看应该对等于MVC中M的功能了，也就是比如webwork action，一般人肯定不喜欢对远程对象（比如EJB,WS)调用的时候是自己直接操作XML API吧，除非是异步Message。

而且我觉得这种C/S应用采用XML、SOAP通信实在是有点浪费资源（当然如果依靠js也许是唯一的选择），本来服务器端客户端很多时候都是自己完全可控制的（并不是真正的B2B service）。像.net那样扩展soap之后可以透明的在http，tcp，xml，binary之间切换的话就好得多，这也许是OO封装的好处吧。

to shenli：
我把这些低层的细节都用 OO 的方式封装好了，给你一个 OO 的 API 你来调用，那么对你来说不就是 100% OO 的了吗？如果能做到这一点，你是不是会感觉会好些了？开个玩笑，呵呵。

不过我一直觉得在表示层最需要关注的其实不是 100% OO 这样的问题，实际上是一种快速应对变化的能力，当然我相信 OO 肯定对这个目的是有帮助的（良好的 OO 设计更有利于拥抱变化）。不过如果暂时做不到我觉得也不是非常大的问题，只要能有效提高开发效率就可以了。

100%OO本来也许本来就是不可能的，呵呵。不过我同意你的看法，从实用角度，我觉得很多时候许多smart框架根本就用不着，更不用说自己写了，花了百分之N的努力解决去解决百分之M的问题（n>>m，也许是我见识有限）。不过从开发者的角度上来说如果不追求一些艺术性写代码实在是无聊透顶。

我有个疑问就是js+html的东西怎么能OO，你们是不是有什么好的方法啊？
（并且这种OO好像是以页面的速度为代价的）不是很清楚，但是我现在以事件驱动来开发的话，速度的确是有点下降，并且页面上难免会有冗余的html。或许这些都有好的解决方法。

这的确是个好主意，但是如果开发过程中需求不断变化，这种原先的界面原型可能就要做较大的改动。（因为对界面开发的人来说只有查询修改删除等基本操作，但是我现在觉得界面还是不能脱离业务逻辑的，否则开发出来的界面肯定是单调乏味的，没有系统性）

还有就是DHTML+js+xmlHttp对浏览器的要求比较高，经常在大多数的电脑上运行是正常的，而就有部门电脑通不过的时候就要为解决这个莫名其妙的问题伤脑筋。直到现在还不知道如何解决那个浏览器崩溃的问题。
我不反对DHTML+js+xmlHttp，但是有些问题的确是解决不了（水平限制），希望有这方面开发经验的多谈谈这种模式的开发的一些具体问题的解决方法。谢谢

这方面我们也没有解决得很好，就是没有达到有真正的数据库参与时的那种真实感，所以现在其实还是只能做一些比较简单的功能。我们希望将来能做的更好一些。