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

2007-03-28 20:12 by Bing
@Jeffrey Zhao
首先我要给您道歉一下，上次说话我没有注意分寸，也没有认真准备好我的言词，说话鲁莽了，真的很不好意思！这次我想理性的和您交流一下（可能以我的辈分和身份完全及不上您，但是请允许我现在的所知和浅薄，谢谢了啊）。首先是对效率的理解，很不好意思，这个东西我上次并没有讲清楚，从效率上看，主要是一个在服务器端还有一个在客户端，两者兼而顾之应该才称的上效率。ASP.NET目前的问题不是效率上的问题，而是实际开发的问题。我不是把别人都当成傻子（我从来也未曾这样想过），而是对ASP.NET的一些做法提出自己的一些想法，ASP.NET目前将表现层、逻辑层甚至实体层都进行了从头到尾的封装，这个做法很好，并且极大的减低了学习者的门槛，可以直接进入事件机制的开发模式。然而给开发者（尤其是初学者）带来的问题是：如何深入？ASP.NET通过UniqueID、ViewState、Session等等数据格式提供了一个很好的保持状态的机制，然而是以损耗资源为前提的，于是我们很容易看到ASP.NET开发出来的网站的速度往往很慢，如果看看源码，会发现里面有很多的ViewState，各种奇怪的名字，各种奇异的Javascitp，并且回传一次是回传的整个页面的数据，因而回传的数据量比较大。另外由于很多数据都是动态读取的，并且喜欢使用DataSet，很多并不需要刷新的数据也要从数据库里再读一次（当然缓存是另一种解决方式）。因而一般情况下ASP.NET的网站速度慢，这个不足为奇。

好了，觉得扯远了。我并不是要否认掉ASP.NET的东西，事实上我对ASP.NET这样一个东西相当的热衷，它的理念、模式、设计方法让人很着迷。问题嘛，只是它封装的过于好了，对于初学者来说既是一件好事也是一件坏事，当然会有一个逐步深入的过程。那么对于ASP.NET Ajax，我深入分析过它的源码，很让人震撼，微软居然能将Javascript变成像C#一样的功能，如果说要使用Ajax库的话，我的感觉是没有什么比得上ASP.NET Ajax，当然是否需要这样做，这是一个问题。另外就是ASP.NET Ajax这个东西的效率问题，出了上面一段的ASP.NET 本身就存在的问题外，我们还可以继续下去 。如果仅仅只是在传统的页面上加入几个UpdatePanel，然后实现一个分页、排序什么的功能，我想这个就达不到Ajax真正的功能。实际上我想的更多的是如何将整个网站桌面化，于是我们传统的所有页面最终都要归到一个页面，对于把握不太准确的人来说，这个无疑会对服务器端的效率造成影响，事实上我所知道的管理服务器的人，也都说ASP.NET的网页的确很耗服务器的资源。另外一点就是客户端这样一个效率，Javascript在客户端运行并没有什么效率问题，问题在于回传，首先是JS文件大小的问题，一般情况下，压缩过的JS文件，就核心部分是100多K，这个数据不小，我只能这样说。其次当你使用一个组件的时候，就会加上相应的Javascript文件，这个文件虽然一般只有三四百行，但是也绝对不少，因为我们要使用的组件往往不只一个。另外，据我分析，ASP.NET Ajax 并没有做到该回传的回传，不该回传的不回传，而是传统的将客户端的所有数据传递到服务器端。然后从服务器端渲染的组件不是一个UpdatePanel里面的组件，而是所有组件，只是传递给客户端的是UpdatePanel里面所有的字符串，如果组件过多，特别是桌面式的开发，毫无疑问，是不必要的损耗。因而会发现这样一些问题：ASP.NET Ajax并没有怎么改变传统的开发，而是改变了某一个页面的一个局部的开发；ASP.NET Ajax并没有使速度快多少，而是没有刷新；ASP.NET Ajax并没有使页面的打开速度加快，而是减慢，服务器越是不好，越是慢。这些是我实际开发当中的体会，空穴来风。当然也有可能能力有限，并不能掌握其中的精髓。

另外说说我对“扩充性、维护性”的理解，对不起，我只是一个业余的爱好者，对这个词的使用并不专业。通过我的开发经验，如果所有的开发都让微软给我们的一套开发模式来看，实际上我们能发现所有的逻辑和代码可以全部放置到表现层，开发速度很快，也并不需要掌握太多，只是我发现的问题是：当开发的产品需要升级怎么办？我往往只能重新来一次。因而这样一种方式对我所理解
“扩充性、维护性”是相当低下的，实际上在以后的开发中我更喜欢将不同的开发归结到不同的层次，这样的好处是我花了一个通宵+两个下午的时间就将我的Blog系统从Access移植到了SQLServer上。ASP.NET Ajax虽然封装的很好，但是由于组件过多，往往使得逻辑层过度依赖于其组件，而导致自己维护起来的问题有点大。

最后我还是想表示一下道歉，我并非有意攻击任何人，请您原谅我的话语。此外，我想和您探讨一下Ajax本质的东西，Javascript这一门脚本语言本身并不是用来搞开发的，而是用来实现客户端的一些功能，比如验证、交互，其初衷是为了提高交互性和用户体验。目前Ajax可以说是对逐步被人们所重视的交互Web的一种想法，这个想法基于数据本身的膨胀和不比要的数据垃圾而提出的，同时没有什么新的东西，一种纯粹的理念，因而很快被人们所接受，同时它减少了回传、减少带宽的占有、减少了服务器的压力，最终达到的效果是提高用户体验，因而我十分的赞同这种做法。然而人们逐渐发现Javascript能做的东西比人们最初认识的要多，于是出现了不少Javascript原本所不能及的事情，比如模仿软件操作、模仿桌面操作，甚至直接将MVC模式照搬到Ajax上来。我的感觉是“无聊”。Ajax并不擅长这些，也并不需要这些，Ajax只是一种用来提高用户体验的工具，而不是人们所畅想的万能的上帝。我希望在Ajax风气逐渐在国内蔓延的时候能认识这一点，开发不是停顿在客户端，更多的依旧是在服务器端。当然如果您不同意，还请多多指教。

@怪怪
看了您在我blog上的留言，还真怕找不到您呢！呵呵，别以为我是来找茬的，我是来道谢的，您让我认识到了自己的潜在的毛病，十分感谢。同时有几点我想答复您一下，当然这不是什么攻击，而是一种交流，希望我的言语没有什么让您看到了不舒服的地方，对于像您这样有着许多开发经验的人来说，我往往抱着无限的敬仰。

首先我想说的是，我并没有什么值得炫耀的地方，无论是经验上还是资格上，我并没有“老王买瓜”的任何想法，因为我分析过ASP.NET Ajax和Magic Ajax源码，并不是稍微研究了一下，而是整体的研究过，认真阅读过源码，并尝试去理解它对整个回传、渲染机制的把握。因而我说的那些话并不是为了突出自己的好，而胡说一通，而是通过我的实际开发而验证过的，我想我的Blog系统应该是个不错的例子，如果您细入的了解一下的话。当然如果您有兴趣的话，可以让您分析我的源码。我也并没有特意说明自己的无组件模式是一件什么大不了的事，更没有完全否定掉控件的意思，要不然这么多天才做的开发工作不就白费了。虽然您的理解可能与我的本意不太符合，我只是想说明一下ASP.NET 控件的实质，以及增加人们对控件的认识，控件从何而来。如果您看过一些别的介绍，实际上我非常清楚的说明了它的弊端和不好，但是我的确发现将整个网站当成一个页面考虑的话，控件会变得异常的多，把握不好的确会产生很大的浪费，无组件只是一种思想而已，更没有认为任何人都是采鸟的意思。我更倾向于动态加载组件，不可能摈弃组件而回到ASP的时代。

另外，对于您其他的几点观点，我虽然不赞成，但是也没有反驳的理由，因为您和我站在两个完全不同的观点看待问题，我是站在自己开发的立场上而看待的，而您是站在整体上来看待整个问题的，自然我的目光可能不及您的视野。ASP.NET Ajax的确是很完备，这是任何一个大型框架所应该考虑的问题和应该的实现的，只是我觉得可以从另一个层次来了解完备，完备的.NET Framework的确可以在服务器端有非常出色的表现，但是并不意味着客户端也应该需要承受同样的压力，Ajax TXT的正式版只有十几K？这个我不敢想象，据我所知，最基本的框架就有100多K吧？这个不是个小数目。同时还有很多控件都有各自对应的Javascript代码，并且代码量都不是一个小到可以忽略不计的数目。于是我想的是，对于小中型的开发，Ajax TXT过于臃肿了一些，还有其他关于回传和渲染机制方面的问题对@Jeffrey Zhao 的回答中我已经阐明了。如果对于大型开发，特别是当速度和效率对本身开发没有什么影响的情况下，我当然乐意选择Ajax TXT，因为微软做的的确很棒。

最后嘛，得谢谢您，我为我上次的评论而表示抱歉，您指出的很好，也很深刻，的确，人们需要尊重。在现在这个时代，我想需要的更多的是对技术本身的把握，而不是一味的追求技术，更应该认识到技术本身的艺术和问题，因而人与人之间需要的更多的是讨论，而不是一味的强调什么对，什么不对。对于您这点，我非常赞同。

PS：Ajax是激起了人们内心深处和机器交流的愿望，Adbe、Microsoft、Sun等公司都在为这个外来的市场而针相提出相应的解决方案，当然对于一个中国人，我也非常希望能有一批异常优秀的年轻人站出来，站在技术的前端，充分认识已有的和没有的，过去的和将来的，开发出一套属于国人自己的技术，虽然很难，但是我们一直努力着，拼搏着。上面的话语没有任何攻击的意思，即使我错
了，希望能指出问题所在，我会接受的，谢谢。