题记：此篇文章没有什么特殊的意思，只是希望大家能从中悟出些什么，我们没有最终决定哪个对，哪个错。这个辩论由我引起，从老赵的Blog开始，欢迎大家提出观点和意见。

2007-03-27 11:26 by Bing
我一直不太明白的一件事情是：为什么像您这样的男子也在一天到晚推崇ASP.NET Ajax这东西？实际的开发中真的需要这个东西吗？它过于庞大，对效率的大打折扣，还有使用这个东西后网站的扩充性、维护性的贬值……这样一些本质的东西您认真考虑过吗？我个人觉得只有好好思考过这东西后再来教别人什么是对什么是错才更好些，不然会使那些精神饱满的年轻人被引入一种误区，认识不到事物的本质。

对于想实现无刷新上传文件，这个是做不到的，限于安全性方面的原因。除非激活ActiveX，然后将数据使用XML分割，然后再上传到服务器端，通过解析相应数据再保存到服务器上。唯一能做的事使用IFrame，但这个并不称之为无刷新，更不必要结合UpdatePanel，不知我说的对不对。

不好意思，说的话语中带了点刺，我并不是这样的人，只是希望您能认真地思考其中的利害，然后给别人更好的指引。


2007-03-27 11:44 by Jeffrey Zhao
@Bing
我其实并不觉得我在推崇ASP.NET AJAX，我只是觉得这是ASP.NET平台下最好的AJAX解决方案，再加上感兴趣，因此一直再对它进行研究和推广。
“实际开发中真的需要这个东西吗？”关于这个问题，我想说的是，如果您的应用需要使用AJAX，那么ASP.NET AJAX框架应该是ASP.NET平台下最先考虑的框架，它能极大地简化AJAX开发。
“它过于庞大，对效率的大打折扣”庞大，我想应该您指的是客户端吧？服务器端的程序集再庞大也不会影响什么，而且其实它也不庞大。至于客户端，可能只是添加了一个100K左右的JS文件吧，加上缓存，它不会对性能造成很大影响的。
“扩充性、维护性的贬值”。其实ASP.NET AJAX对于AJAX功能的良好封装已经大大提高了可维护性了，我在真实项目中使用的经验来看，它并没有带来什么维护性方面的损伤，反而它比其他的AJAX解决方案要好很多。至于扩充性，您是指什么呢？
不过我可能的确需要强调一下，什么时候应该用AJAX，什么时候不该用，这并不是框架本身的问题，而是整个AJAX技术应该探讨的。
至于我说的这个“UpdatePanel的AJAX上传”，这里的AJAX的确只是指“AJAX形式”。:)
但是我认为这个扩展是很有必要的。现在我做的，并不是“为了无刷新形式上传”而作的组件，而是“为了让UpdatePanel兼容上传组件”。这是使用UpdatePanel时的一个扩展，为了让UpdatePanel更好地工作，方面大家的开发。

您最后给我的建议我觉得很好，我的确需要好好考虑这个问题，谢谢您的建议。希望我能和您多多交流，能多听到一些反面的声音。:)


2007-03-27 19:16 by Cat Chen
@Bing
我也认为ASP.NET AJAX不是非常好，但在ASP.NET专有领域内已经是最好，这点看法和Jeff差不多。暂时来说，要求更灵活的AJAX设计方式，可能还是RoR等更方便一些。ASP.NET AJAX总想做一个大Framework，成就了不少，却也成了一个大包袱。


2007-03-28 16:02 by 怪怪
@Bing
老赵说的我就不重复了。我说说我的想法，PageFlakes，虽然没有用ASP.NET AJAX框架，也用了AJAX的客户端文件，如果你有一种需要，你就免不了要承担这种需要的开销，区别只是到底是prototype.js还是其它的。关于框架本身，前一阵子我回老赵一个贴，说感觉ScriptService没有必要，我都是自己写Handler自己封装。但是对我来说，有这么一个理解：面向对象式的抽取，对于JS比对于C#还重要。抽取出来的共同部分越多，代表着发送到客户端的代码越少。最后我的做法导致，如果我不抽取，我的代码体积就会很大，我自己封装，写出来的东西字节数比ASP.NET AJAX小不到哪儿去，可工作量却明显的增加。

对于老赵搞得这个上传，我个人也持保留态度，UpdatePanel，就如Omar所说，在一个非AJAX应用到AJAX应用的提升，我赞成这种方式，因为反正也是那些开销，多些脚本就少些刷新。但对于复杂一些的应用，肯定还是单独开发的好，因为UpdatePanel主要是两点，服务器端开销大，可扩充性有限。前阵子下了个R.A.D还是谁的带进度条的上传，打算无耻一些，等闲下来Reflector之，简化后实现一个控件，并把客户端移植到基于Atlas(减小同样功能的代码的体积)。

对于Cat Chen同志的RoR论，我也持怀疑态度。我不相信比如说我实现一个无刷新、带进度条的上传，用RoR还是使用Atlas能有什么区别，工作量能有什么差异，如果真为了追求编写客户端的效率，那一定是Orcas，甚至Script#，RoR能给我做什么？当然除非RoR那边已经有这样的东西，我白拿过来用，但同样的，我实现一个这个，也照样可以白给别人用。也许我说的不对，但确实没时间细了解，如果你现在确实在RoR的认识上超前大家一截，不妨说说这样一个应用，ASP.NET怎么做，RoR怎么做，一对比，实事面前谁不服都不服行不是:) ?向我这样的现实主义这立马倒戈投诚，毕竟现在我看到的事实就像Scott说的，二月份第三方统计的全球六大网站，4个用的ASP.NET，其中MySpace和Ebay也不是微软的站，甚至一些部分是从其他技术移植到ASP.NET + SQL Server，并获得了改进的。哪怕把这4个网站用Alexa那种不靠谱的排名，也都是前20，这前20还得加上Google的Orkut等好几个ASP.NET站。对于我这种人浅薄的见识来说，即使微软给了相当优厚的条件，这些公司也不想搞砸他们的根本，所以显然ASP.NET还是靠的住的玩意儿~ 不过得重申一点，我不认为RoR不好，因为我不了解，但我相信ASP.NET或JSP都能变得更好，而且我自己在快速开发上找到自己的方式的话，使用ASP.NET也能做到RoR表面上看所能带来的一切，至于我看不到的非表面的东西，这就需要先行者带路了 :)。

返回到Bing身上，我开始以为你没有深入这一块才会说出一些话。比如异步提交之类的，你用Atlas，完全可以只用它的这一部分，你自己写的不会比它有什么不同，只要你敢于随便用，Atlas比你自己写也不会有什么不灵活，最终就变为一堆素材(你的也罢，微软的也罢，其它的也罢)，如何组织的问题。至于老赵的本意只是方便那些目前需要UpdatePanel提高工作效率的人。幸亏我发帖前开了你的站，真是有眼不识金镶玉，原来你有自己的玩意儿后头藏着呢 :)。不过最后还是要说，Atlas的效率未必像你说的的那么低，至于跟不跟风这种问题，无论跟Prototype.js还是AtlasCompact.js还是自己构建，都不是太难的、影响个人竞争力的核心技术，不愿意自己费劲琢磨和当年选取方向时的随机性罢了，也不必把大家都看成傻乎乎老外说什么是什么的傻子。最后，祝你成功。


2007-03-28 16:20 by 怪怪
你的东西很棒，但你的风格我有点接受不了...。你的博客仔细看了一些文章，说几点：
1、比如对Repeater的评论完全正确，其实我认识的初学者现在都知道这种问题，可你却认为大多数人不认识这个控件。
2、你的很多思路其实很正点，但文章中老让人感觉你在老王卖瓜，说白了除了菜鸟谁也受不了这个。比如说你的无组件的方式，对菜鸟宣讲听着很牛甚至代替了ASP.NET的传统开发模式，但实际上对于任何一个有经验的开发者，说实在的在C#中实现一个这个比用ASP还容易，这种语调容易造成交流障碍。
3、你说Atlas多大，你的多小，其实你的也是有压缩后十几K，实际上AJAX EXT正式版真正需要发送到核心的JS压缩后比你大不了多少，其完备性却是你所不具备的，并且这种完备性对于一个比较完整的AJAX应用，绝对是必要的而不是你所说的浪费。你说老赵在误导，可在我看来谁在误导不好说。
4、我上面说的，不是为了表达我对你的不爽，这没有意义，只是我个人感觉人和技术要并作，该圆滑的地方圆滑是为了让大家都舒服，这是对别人的尊重；另外你的东西现在还是初期，不完整是正常的，我没有看不起的意思，但你把话说得太大了...
5、对于你所为之兴奋的这种轻量化实现方式，就直接与HTML打交道来说与ASP相差不远了.. 效率上肯定是最好的，但这不是只有你知道，否则别人都是傻子了(其实你的很多发言都有点把别人无知化)，但不是现代化软件工程的发展方向，为什么JAVA、ASP.NET要选用一个大幅降低效率、提高复杂度的方式，我想是你需要考虑的。虽然我个人认为ASP.NET的实现有错误，但错了之后可以走上正确的道路，而非是倒退(在WEB方面就是又回到和字符串打交道，只有简单的封装，而放弃了大量应有的进步)。

我发比较直接的帖子，一般有一句话，就是我到底是好意歹意，得看的人自己衡量。有志气是好事，希望你一路走好。