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

2007-03-29 12:42 by Bing
@怪怪
哎呀，对于我上次的发言，我只有一个词来形容“惭愧”，我明白的，“尊重”，这堂课，我会记住您的，谢谢。我测试过Atlas的传输量的，因而才会提出UpdatePanel做的不够好。24K的确不太大，正如我上面所说的，如果要一个网站完全的桌面化的话，问题就大了。如果您用FireBug看看我的Blog的传输量的话（注意，我在这不是要标榜我的Blog系统，只是觉得有个例子更具有说服力一点），您会发现PostBack到服务器端的不会超过1K（排除回复的可能性），然后从服务器端传到客户端的一般不会超过10K（除非文章比较大）。当然我并不说对于一个像ASP.NET Ajax这样的大型框架，传个32K不可取，只是作为追求者，我们能做的更多。还有就是在客户端的代码量，这个数目相当“可观”，您做过相关开发，这个“可观”的数字我想不会不给与理睬。您应该查看过我Blog的一些Javascript代码，的确有上20K，但这些代码没有一个Byte是需要回传的，请您理解这点。上面的核心Ajax只有不到10K，剩下的上10K是我自己开发的在现编辑器所使用需要的，还有就是一些动态验证所需要的，并不是您所理解的需要回传的代码。

“关键的问题是怎么灵活应用上，在我看来，所有的问题都是咱们如何认识事物的问题，该不该维护状态，用什么方式怎么维护状态”这句话说得太好了！我没有任何反驳的理由，对状态的理解完全在个人。说实话啊，我除了学习过Flash里面的MVC设计模式之外，然后看过一个XMLChina这个论坛的设计模式之外，我对设计模式几乎是个“门外汉”，对您所说的23种设计模式，我倒是被吓出了一身冷汗，居然那么多！呵呵，不过在实际开发的过程中，我能发现不同的代码应该有不同的放置地方，很快我发现如果放置的地方对了，那么代码将会变得很“艺术化”（请允许我使用这个词），并且代码量急剧地减少，最后是发现居然能很好的扩展和维护，这个与其说是我的预期效果，倒不如说是我的意外收获，当时我唯一的目的是为了减少代码量。我适用以下几个层次：“DataAccess,DataRules,DataExcute,DataInstance,DataFramework，DataShow”，然后对所有数据的操作，只有一种情况，那就是单个或多个，于是每个层次下又对应一个“Single”和“Multi”层次（以上的说法应该很不专业，这些词也是我自己胡编乱造的，加上篇幅关系，我没办法让大家理解）。然而我很快也发现，这种方式能很快地融入到我的所有开发中来，并且能很好的解决我实际开发中的所有问题。啊。。。不好意思，说走题了，说到这，我稍微有点兴奋了。。。回到主题上。

至于效率问题，我明白您所说的意思，只是我觉得在我们所能及的地方，能将Pefermence做到最优，为什么不做呢？如果在不改变我的设计体系的情况下，我会优先考虑效率，甚至乐此不疲，虽然我也赞同一种说法“随着硬件的发展，效率已经不是我们太值得关心的地方”，但是怎么说呢？我想我对我所开发的东西不是当作一个做完即扔的弃婴，而是一个充满生命活力的孩子，我喜欢看着我的孩子能健康快乐的成长，而没有瑕疵。您的观点我很赞同，我只是提出另一种思想而已，在现代的IT界，据我所知，很多老板需要的不是有思想的程序员，而是编码的机器，尤其是在中国，大部分老板并不懂代码。这算是对这种老板的一种“回敬”吧，也算是对作为程序员的一种“庇护”。当然很可能，实际的生产过程中，利益往往大于思想。不过作为开发人员的我，在同一个项目中，我不关心别人做的怎么样，对于我负责的部分，我尽己所能，也算是问心无愧。

您其余的观点我都相当的赞同，都说到了点子上，我没什么好说的，只是我所希望的是，能更理性的、站在更多的立场上看待一件事，势必要比单纯的宣传要好的多。

至于关于动态加载组件的方式，我这个也一时半会说不明白，也解释不清楚，在加上时间的关系，我可能要放在以后的时间里在我的Blog上仔细阐明了。

@Jeffrey Zhao & @怪怪 & Everyone
最后我想说的是关于ASP.NET Ajax中的一些问题，这些问题影响到它本身的生存问题和发展。

首先是浏览器的前进和后退功能，受限于UpdatePanel本身的回传的缘故，ASP.NET Ajax本身没办法做到支持浏览器前进和后退的功能。对于一个桌面化的网站来说，或者说对于任何一个软件项目来说，不能前进和后退，这是个相当大的问题，如果解决不了，这是个很严重的问题，在我的Blog里面，如果您使用IE或以IE为核心的浏览器的时候，会发现支持前进和后退的功能的，并且没有任何限制（呵呵，不好意思，再次申明我不是标榜我的blog，对于已有的Ajax框架，我实际上做过许多深入的研究，我知道这些Ajax框架存在什么样的问题）。

其次，是关于灵活性的问题，我之所以说UpdatePanel不够灵活，不知您有没有考虑以下几个问题。1.随着桌面化方向的发展，势必在一个页面上会有多个UpdatePanel，同时在一个页面的User Defined Component 里面也可能存在很多个UpdatePanel，很多情况下，往往一个事件被触发，只需要Response是一个UpdatePanle里面的数据，而不是所有的数据，但是实际情况下，ASP.NET Ajax 会Response所有的UpdatePanel里面的数据，这是不是要被解决的问题呢，如何控制。2.如果能控制，我又该如何使得User Defined Component里面的UpdatePanel事件来触发页面上的另一个UpdatePanel的事件响应，从而使得其里面的数据得以更新？

最后，对于譬如“在线编辑器”这样类似的组件，它们所生成的HTML和javascript代码都比较大，我显然很希望在进入首页的时候就讷能生成这些代码，只不过加一个“display:none"，然后在进入某一篇文章的时候，将“display”设置成“inline”。而不是每次进入一篇文章的时候都需要加载相同的代码，这个ASP.NET Ajax可能又欠缺考虑了吧。不知各位在实际开发过程中，有没有深入去了解这些问题，这些实际上是我在桌面化应用当中所遇到的很大的问题，当然这些问题我都以我的方式解决了。

好了，一说又是半天，真爽，还没吃饭呢！上面我所说的问题，大家也可以完全不赞同，自然也可能有很好的解决方案，我只是提出来一下，具体的大家还可以再探讨。祝大家今天活的自然！


2007-03-30 04:12 by 怪怪
@Bing
哈哈你和我一样，我就是被老赵引出来的，你不也是？ 但我有一点和你不一样，即使我不说话我也总受外部世界的影响，所以看法变得很快 :P。

我指的传输是说JS的传输，你说的回发，UpdatePanel方面想必你和老赵谈过，你俩比我清楚。我自己是不用UpdatePanel的。另外，一个站只有一个页面，这个我也琢磨过，PageFlakes也是，但是照样用了Atlas的核心部分作为基础，因为你所抨击的在很多方面都是事实，但那只是UpdatePanel，而并非Atlas的核心。回发的过程，如果仅用WebService的方式，绝非达到你说的那种夸张的情况。另外UpdatePanel服务器端的渲染问题确实可怕，所以我也是同意你的。我表达的意思是，用Atlas的同时，完全可以避免使用UpdatePanel和其它的影响效率的方式，所以Atlas并不如你的感觉是一个鸡肋。

最后一个为什么要使用一个流行框架，因为大家都在用，比如说这个框架存在问题A，我开始应用的时候不知道，这就是一个隐患，但是我可以跟踪别人的言论，从而及早发现这个隐患并排出。而我自己写这么一套东西，即使不费劲，但是由于用的人少，隐患并非是不存在了(除非我自信所有的事我都知道)，而是不可能被提早发现。前一段时间AJAXControlToolkit的DragDropManager出现一个BUG，而这个Bug实际上是Atlas核心的Bug，而这个Bug在未来肯定会影响到我，因为社区提出来，我自然知道什么情况下我能碰到，它是因为什么产生的。但假设另外一种情况，我用的是自己的代码，就需要花大量时间找出因为所以，然后结果它。

比如前进后退，在我看来只是一个小问题，决定不了我使用谁这样的大事。因为大家都有这种需要，肯定会有人解决，你解决了我使，我解决了他使，这就是你所说的跟风的另一面，它将大量的节约我的时间。

不多说了，每次我总是起头吵架，把老赵这里搅得一团糟，再次致歉了 :) 。