我不想再次引发争论，但我希望可以加强这方面的讨论。

边吃早饭边看新闻，看到了老赵（大家都这么称呼，比较亲切，我也这么称呼吧^_^）的一篇为WebForms说几句话，以及一些ASP.NET开发上的经验（上） 不管我是不是被老赵纳入了“跟风”MVC的行列，还是有一些话想说。

首先还是强调一下个人立场，我不是老赵文章中说的一味反对Web Form，而只是去拥护MVC的人（如果暴露问题就属于反对的话，我之前几天说的MVC(CTP)的问题要远远多于Web Form）。对于我来说，目前对MVC也只是尝试，但是拥护MVC的情节是早就有的，至于对Web Form一些缺点的体会和归纳，是我长久以来得出的结果，和MVC的出现无关（当初TT.NET推荐我用ASP.NET1.1的时候，我花了一个多月了解和测试.NET1.1，其中一些缺点我当初就和他讨论过，用了.NET1.1几个月后我就已经在嚷着要MVC了）。

还有一点必须强调，我这里所说的Web Form 和MVC都是他们最基本的模式。

我这里要讲的也是符合我开发背景的，关于企业级系统的开发，没有任何贬低Web Form的用意，毕竟两者面向的开发对象有所差异。

一、       对于老赵文章内容的看法

我赞同老赵对于Web Form 的大部分看法。对于MVC和Web Form上面的一些差别，我建议老赵了解尝试了MVC（不一定是目前的ASP.NET MVC CTP，Scott讲的只是使用技术方面，并没有对MVC本身具体展开）之后再做讨论，不然很容易拿起石头砸自己的脚（比如老赵说的关于ViewState的观点，我完全赞同，并且ViewState也确实是在很多情况下可被取代的。但这也正是MVC赞同的，所以才会有MVC中V的现行模式）。

当然有一个客观事实我们必须承认：每个人的开发背景不同，所以对于技术的需求和看法也是不同的。我们不应该对某项技术偏执的反对，但同时我们有暴露和讨论这些技术缺陷的责任，同时包括Web Form 和 MVC。暴露问题不等于反对，如果我反对一项技术，我根本不会去评论，因为我不是评论家，也不是喜欢靠挖苦别人来发泄自己不满的人。中国有句古话：爱之深，痛之切。

二、       我个人的一些体会

每个人的体会都是跟他的经历和环境有关，我也不例外。我上大学没有选择计算机专业，而选择了物流专业，因为我看中了物流+IT(e-c)这个方向，并且对于计算机特别Web方面，我是自信自学能力很强的。这也决定了我在之后的很长一段时间内，需要以企业级的Web开发为中心（为什么是选择Web而不是Win Form，以后有机会我会具体谈谈）。

我下面来谈一谈为什么我更青睐MVC(或者说打接触ASP.NET一开始就期待MVC)的原因。这里我没有反驳老赵观点的意思（因为我们面对的需求可能不太一样），对于老赵的敬业我是发自内心敬佩的。

但这个问题上我很客观，还是要拿老赵的一句话作引子：“不如编写一个内置1000个动态Button控件的页面，然后部署到服务器上，我保证运行的飞快”。

这种测试在我所经历过的企业级的开发中，是行不通的（即使一些朋友做的外包的小工程（也可能是大系统中的一小部分）我们完全可以有理由相信这样的结果）。我觉得原因有这么几个：

1、企业级的发开更注重“安全”“可靠”和“使用效率”。“使用效率”可以理解为“用户直观体验”和“数据处理能力”的总合，然而对于Web来说，比单机软件更要多一条，就是“传输效率”。所以“运行的飞快”不是企业级系统追求的最主要目标，“运行的爬慢”也不是企业级系统最需要解决的瓶颈（这种系统往往硬件上的投入不成问题。只是往往，万事不会绝对）。

但是有一点似乎被很多人忽视了，就是一个程序员解左右不了的问题——B/S的实际传输速度。对于一般的网站而言，使用PostBack（包括cnblogs也有使用）和不使用PostBack的网页，信息流畅的情况下，差别微乎甚微。即使在网络条件十分差的情况下，当你执行了PostBack后IE卡住（延时）了，你等待几秒钟，几十秒钟，甚至直到超时了，你刷新一下，一切又恢复平静。试问，对于企业级的系统，允许这样的情况屡次发生吗？

让我们来举一个例子（由于企内系统不一定每个人都熟知，我就举一个大家都能理解，但是不是最贴切的例子，因为技术上不能完全的等同，但流程和道理是相似的，并且是在我所学专业内，我可以十分负责地提供说明。特此说明，希望不要误导了大家）：

比如我们经常会去超市购物，收银员拿着一个红外线扫描仪（扫描枪），对着条形码一刷，一般在1秒钟内你可以听到“嘀”的一声，等刷玩了，你就可以付钱走人了。一切看起来再普通不过，波澜不惊。但是你知道“嘀”的一声发出来之前发生了什么事吗？这是前台和后台的一次对话（就1件商品而言，并且是最普通的情况）：

POS机（Point of sales）：“我有商品需要卖出,这里是条码。（当然还可能有POS机编号之类的，这里不用考虑）”

服务器检查完条码正确、可用性，并搜索价格和库存：“可以出售，这里是价格”

POS机：“收到。”（嘀）

同时服务器需要扣除对应数量商品库存，处理账单（所有商品输入完之后），如果库存到达“预定周期”的存货底线，马上会发一条消息到采购部门，要求马上送货，从而拉动整条供应链开始运转（从这一点上来说，很有可能你这最后一“嘀”，一条生产线开始运转，一架飞机就马上从美国飞过来了，当然不只是为了你一个人，是不是很有成就感^_^，闲话）。

这个过程中，POS机和服务器的通讯，我们可以简单的看作前两句。因为服务器给POS传输结果是很快的，也是不可避免的，所以我们暂不考虑，我们来研究一下第一句话——“这里是条码。”

按照PostBack的思路，可以这么做：条形码输入在一个TextBox框中，由一个按钮负责回传，这时候可能会把另外的一些无关的控件信息也输入进去(这些控件可能同样不只是显示，有PostBack功能，所以ViewState不可避免)。

按照MVC的思路，可以这么做：条形码输入在一个TextBox(input:text)框中，用一个按钮把EAN13=690xxxxxxxxxx , PosNo=xxxx 等等关键信息传入处理器即可。

换句话说，普通的Web Form 模式，在这里会产生比较多的数据量（老赵也提到了），并且需要服务器去重构并分析，而就一般MVC模式而言，可以直接对服务器发出一条指令(URL)，几乎没有多余的信息。

如果一位服务员刷完条形码过了5秒钟还没听到“嘀”，或者干脆“超时”了，这对于超市来说意味着什么？

拿沃尔玛说，2005年的时候5139家分店每秒钟销售8126亿美元的商品（我怀疑资料上统计错了，但数量很大时肯定的），光POS机一个环节就要担负这一秒钟内的多少毫秒。熟悉工艺流程或者制造流程的人肯定知道，对于这种对把握时间精度的要求相当高的系统来说，延时哪怕1秒钟有多可怕。

PS:我之前已经说过这个例子不是最贴切的，所以大家千万不要以为POS就是这么工作的，也不要因此去追究POS环节的种种其他可能（事实上确实就是其他方式）。因为至少POS目前一般不会使用Web技术，一般的商店也只是局域内处理，速度差别一般人感觉不出来。因此大家也可以简单地理解为不同两个公司之间Web上订单的传递（实际还有很多其他更复杂的环节），他们可以是跨公司、跨城市甚至跨国的，并且数据传输是连续的，这时候数据传输越少，就越快、越不容易出错，而且可以直接提高“使用效率”（就象物流成本的降低直接作用于收益一样,它不是“生产”环节，而是额外的“成本制造者”）。这种情况下，一份订单发出去，结果你页面上持续半分钟一片空白或者干脆超时了，这样的系统是不合格的。而MVC结构“指令性”的URL，可以至少在数据传输这个方面很大限度去避免这种情况的发生。

我还是要再次说明一下，我这里完全是针对企业级的系统而言。

毕竟MVC的出现就是为了解决ASP.NET先前在企业级系统开放上的一部分弱势！

2、我刚才的例子还只是讲到了ViewState的一些情况，对于企业应用来说，其实还有更多的要求，比如——数据传输处理时尽可能少地依赖本地软件和第三方软件支持（Web范围内）。PostBack在这方面最大的不足就是，普遍情况下使用PostBack就必须使用js！不信的话大家可以打开一个带PostBack的页面看一下，是不是有类似这样的代码：

function __doPostBack(eventTarget, eventArgument) {

    if (!theForm.onsubmit || (theForm.onsubmit() != false)) {

        theForm.__EVENTTARGET.value = eventTarget;

        theForm.__EVENTARGUMENT.value = eventArgument;

        theForm.submit();

    }

}

浏览器任何时候都支持js吗？

——非也！

心动不如行动，大家可以马上测试一下！打开你的浏览器（就IE吧，统一一点，我用的是IE7），工具>Internet选项>安全>把安全级别设到最高（别说一般人不会用，我这说的还真不是一般人，再说有这功能你也不能不让人家用对吧？）,你现在重新打开PostBack页面，

还能用PostBack不？

——不能！

对于一个企业级系统来说，为了迎合PostBack之类的种种原本可被替换的功能，让客户冒着其他风险开放js功能（还不只是js方面的风险），这样的系统，这样的程序员，是不合格的！或许光这这些大大小小的“非独立性”，就促使了ASP.NET在企业级开发领域目前进展缓慢的局面。

哪怕是面向中小型客户，如果一个软件需要对方这边注意，那边注意（就比如不提供任何日期格式验证和自动选择，后台却要求一定要用户输入正确的日期格式），这样的软件大家会喜欢吗？当然这里大多都是电脑高手，这点问题都是小case，况且一般也不会用到，但对于你的客户来说，他们没有这种义务！特别是专注效率和可用性的企业级系统用户！

所以微软为了造就ASP.NET领域合格的，强大的（或许是很久以后的事），顺应企业级开发的框架，推出ASP.NET MVC（哪怕是别的，至少原始的Web Form架构不太适应）是

势在必行！

3、至于比较底层控件的效率，虽然我之前说对于我目前面对的系统不是最主要的考虑对象，但是也是必须考虑到的，还是引老赵的那句话来说：“不如编写一个内置1000个动态Button控件的页面，然后部署到服务器上，我保证运行的飞快”。

其实这种测试就我现在的中小企业级开发对象而言有点荒唐（没有贬义，老赵之前也没有对MVC面对的企业级开发现状有深入了解），就好像看一辆汽车是否超载的标准一定是要他发生车祸或者把地盘压断吗？

如果非要测试，这样的单线条的载入速度确实直观上难以判断，我觉得应该这么来：编写一个内置1000个动态Button控件的页面，另外加100个100行的Gridview（使用ViewData），然后部署到服务器上，然后把这1000个Button依次按一遍，记录总响应时间（传输时间+处理时间+IE显示延时，不计算鼠标等操作时间）。同样的显示内容我们用MVC做一遍，记录总响应时间。

这时候你还认为Web Form在这方面没有缺陷吗？当然我和老赵的例子都把数字夸张了，是为了达到比较直观的判断效果。但是即使是更少的控件，在一段时间的使用后（如1天、1周，还是针对企业级的系统而言，他面对的是更多的报表和复杂的页面处理和更多的终端同时运行），数据量可能会远远超过我们的测试条件。

我支持ASP.NET，支持Web Form，也支持MVC。

就面向企业级开发而言，我支持MVC，放弃Web Form的选择，但不是为MVC的出现而放弃。在一定的条件下，我还会选择Web Form。

毕竟没有一种结构是绝对完美、绝对适应任何环境的。一台全自动水洗洗衣机，放到黄土高原最缺水的地方，对当地人来说或许还没有夜壶来得重要。或许……

不同的框架开发出来的企业级应用能不能用？

大家都能用。

目前来看MVC和Web Form 哪个在前期开发速度更快？

Web Form

谁更适应企业级开发？

首推MVC！