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

2007-03-29 12:41 by Bing
哈哈，讨论越来越热闹了嘛。先透露一个小秘密，这是我第一次在网络上和别人讨论，我向来是不管外面发生什么事，我都按自己的路子和想法坚定不移地走下去的，即使是错的，我也错的心甘情愿，走错的路能让自己发现对的路。这次算是讨论开了，也算我作为搞网络近一年的一次见证吧，或许在这孤独的一年里，我已不知不觉走到了一个档次，能在这里和你们讨论，我深感荣幸。:)

@Jeffrey Zhao
先说说您对UpdatePanel的理解吧，您对UpdatePanel的理解相当正确，通过我对源码的分析，的确发现UpdatePanel设计是这样的。既然您和我的理解都一样，那么也不甚么值得讨论的事情，只不过作为业余爱好者的我对效率有一种固执的执著，我在此谈谈我的看法。首先针对单个页面来说，一个PostBack将整个页面都回传了过去，这个PostBack传到服务器的数据量虽然有多余，但是肯定不是太大多，如果ViewState控制的好地话，一般不会超过2K（排除发表文章或回复这种性质），这个数据虽然我不太满意（实际的可能不到800Byte），但是是一种全能的解决方式，没有什么太值得挑剔的地方。问题又回到了服务器端，UpdatePanel渲染的是所有的组件，拿您的这个Blog做个例子，如果我发一篇回复，很显然我唯一需要更新的是这个评论一块，但是比如您的文章、您左边的最新文章、最新回复……这些肯定都是使用诸如Repeater控件将其表现出来的，而这些表现层级有可能又放到了一个User Defined Component里面了，实际上您可以发现这些都是不需要渲染的，既然渲染了，那么UpdatePanel肯定就做的不够好，实际上我设计的UpdatePanel就能很成功的避免此问题，整个页面只渲染需要更新的部分。当然设计人员如果做得好的话，完全可以实现动态加载组件，这样一来的话前面的问题也就不算问题了，因为组件根本没有加载。

@Jeffrey Zhao & @怪怪
另外就是我说到的桌面化的问题。您的Blog只有在回帖的时候能做到无刷新，其它的地方都需要刷新，这谈不上是桌面化，是目前的UpdatePanel不能做到，还是设计本身的问题？相信以您的水平应该早有对策。我开发过桌面Blog和桌面论坛，所要实现的就是完全的无刷新，无论从什么地方进入。下面我就来提提进入桌面开发后所面对的问题。一旦进入桌面开发，所有的页面必须整合到一个页面，这个是必须的，那么所有的页面势必都只能有一种结果，变成User Defined Component，再剩下的问题就是：如何将所有的User Difined Component 整合到一个页面？最简单，也最合实际的做法是将所有的User Defined Component拖入到一个Default.aspx里面，然后根据需要将需要输出的渲染输出，不需要渲染的依旧渲染，只是不输出，不知道我这样说您能不能理解。那么问题也来了，稍微大一点的系统，就拿这个Blog来说，原本在许多不同的Page都有各自的ViewState，都有各自的TextBox，分散在不同的Page里面，它们的回传量不算什么，但是如果将其全部放到一个页面里，这个回传量会递增，尤其对于设计把握不好的人来说就相当痛苦，因为速度不仅没有变快，反而变慢。这样来说的话，我的感觉是还不如不要刷新，并且以往的设计对于松散耦合要做的更好一些。但是这样说是不是桌面化就没有意义了呢？不是，问题又回到了开发者身上，需要开发者对ASP.NET生命周期机制、ViewState实现机制、事件回传机制、状态维护机制、控件渲染机制……都有一个比较详细的了解，才能突破ASP.NET 本身的限制。那么问题虽然又都回到了开发者的身上，但是UpdatePanel是不是又没有责任了呢？我的答案是:UpdatePanel大有可为。很显然对于提交回复，UpdatePanel需要做的事情只有一个：渲染回复Repeater，其余的通通丢掉。对于追求效率的我来说，这个很显然需要更值得深入。

“扩充性、维护性”，这个先赞同您的说法，“与Javascript语言本身无关”，但是需要从另一个层面来考虑。以往的设计是没有考虑将页面整合到一起的，但是当考虑到桌面化的时候，问题出现了，Ajax影响了原先的设计模式的一些地方，不知道我这个说法您赞不赞同？如果您不赞同，下面的观点也就没有太大必要了。既然影响到了以往的设计模式的一些地方，就不能说对“扩充性、维护性”没有影响了。因为很大程度上，我们的代码开始依赖于ASP.NET Ajax提供的控件库。如果当您的页面发生变化，或者说影响事件的方式发生改变，我想虽然微软的控件库封装的不错，但始终都会有一种依赖性。至于我所说的“逻辑和代码可以全部放置到表现层”，这个只是一个结论，我看过一个微软官方的例子，但没有接触很多，我并没有就此说明我们的开发只需要放到表现层，我显然很反对这种做法。

基于对上篇回复我对Javascript语句的理解，下面我针对您这次的话语来做个补充。我对Javascript语言本身没什么偏见，事实上，我想当喜欢Javascript，它相当的灵活，其灵活度要超越我所学过的任何计算机语言，但是同时您也应该有所体悟：Javascript不是不能做大型开发，只是不太适合做大型开发。Javascript多有的对象全部是一个Function，同时Function里面可以有任何多个Function，这样的灵活度与它的设计初衷有关系，可以发现Javascript不太适合做继承、不太适合封装、不太适合归类。至于ASP.NET Ajax将其变得C#化，居然出现了命名空间、类继承这种功能，我的感觉是对Javascript语言本身的糟踏，个人观点，完全不必理会。如果说要做实际开发的话，Ajax有很大的优势，相对于Flex来说还算比较小。但是我研究过的大型项目里面，所有的Menu、Tree、DataGrid……之类的东西全部都用Javascript去实现，只有一种体会：麻烦，相当的麻烦。开发周期比较长，但是我更喜欢使用Flex来开发，虽然最终生成的swf文件有300多K，但是开发周期短，速度快，并且MVC模式在这里面完全适用，老板和客户的满意度也相当高。当然如果考虑到面向用户、适用范围的话，另当别论，这可能要激起Flex、Flash VS Ajax的大战了，然后又激起WPF和 VS Apollo的大战了……呵呵。


2007-03-29 13:53 by Jeffrey Zhao
@Bing
啊，写太多了，我回不过来，我就说一些地方。

首先就是：我还是这么说，ASP.NET AJAX我觉得它更强调的是开发效率（尤其是UpdatePanel），而使用上得性能，因为本身就需要编写大量代码，加上优秀的程序开发人员，所以自然有一套别的方法来开发，这样的开发成本是比较大的。而ASP.NET AJAX将客户端进行各种扩展，这也是为了开发效率考虑的，这个框架的构造的各种模型都能非常方便地辅助开发，这就是它的作用。如果没有这些扩展，我相信JS的使用还是会随着代码量的增加可维护性直线下降。我认为这样的扩展不是糟践了JavaScript，它给JavaScript提供了新的使用方式，而且完全不影响JavaScript的灵活性。我觉得两者配合的很好。

至于您提到的Cnblog方面传输了太大量的数据，为什么呢？因为我相信只是使用一个UpdatePanel将一个Repeater包含了起来，这的特点还是一个：方便，快捷，AJAX效果（当然效果一般）立马见效。

至于JavaScript开发控件的复杂性，的确的确，很复杂。这也就是为什么世界上会出现那么多封装好的组件了，它们的初衷，就是将这些复杂的劳动一次做完，然后可以让别人很方便地重复使用。至于效果如何，个人认为还是可以接受的，虽然自定义程度高的组件的确还不多。

还有前进和后退功能，其实同时支持IE和FireFox的做法由来已久，我记得我也写过这么一片文章在Blog里，但是我觉得封装的不太优雅，但是方向性是正确的，效果也是有的。而至于针对UpdatePanel的前进后退，我想我有空也会开发一个组件为它提供这个功能——而且支持Bookmark，发现您的Blog虽然能够前进后退但是还不能bookmark，我觉得您可以把它一并放入todo list。:)

至于您说的UpdatePanel只能回传所有的UserComponent的数据……不知道您为什么这么说，UpdatePanel的确可以只是回传需要的数据啊。至于最后一个在线编辑器的例子，我不知道这和ASP.NET AJAX有什么关系。

不过，您的一句话让我觉得很振奋啊！“艺术性”，真好，呵呵。:)