一份“大字报”

边吃早饭边看新闻，看到了老赵（大家都这么称呼，比较亲切，我也这么称呼吧^_^）的一篇为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！

【第二份】“大字报”

一、对于了解、学习MVC的一些建议

如果大家想大致了解MVC的现状和为什么在Web Form之后还要推出MVC等等一些问题，可以参考以下文章：

WHY？

为什么会出现ASP.NET平台下的MVC框架？（一看还是老赵翻译的，放第一个^_^）

个人的一点思考：

通过这篇文章，我们可以大致了解MVC的作用，以及一小部分表面的工作原理。老赵做了比较详细的总结，如果你觉得还不够，建议再看一下英文原文中老赵省略的内容。

其中讲到：

The cryptic control ids and sensitivities of ViewState become a serious problem for so-called Web 2.0 sites. The only framework that does not have serious ViewState corruption issues is ASP.NET AJAX. But it is an immature library.

老赵对于这段文字有这么一段评价：

（译者注：事实上，如果您使用了ASP.NET AJAX中的UpdatePanel控件，在客户端与服务器端交互的过程中依旧需要传递页面上所有的ViewState。另外，2006年最佳个人定制页面网站www.pageflakes.com，也是基于当时的ASP.NET AJAX框架开发的，并且集成到.NET Framework 3.5中的ASP.NET AJAX又在各方面有了更进一步的改进，如果武断地称之为一个不成熟的类库未免有失偏颇）。

老赵提到了集成到.NET Framework 3.5中的ASP.NET AJAX，以及作者提到的ViewState，这里先打个伏笔，下文我会继续说到。ASP.NET AJAX作为Web Form发展过程中AJAX技术应用的产物，凭借其与Web From的“巧妙配合”（即使在一些时候用UpdatePanel去装载服务器控件反而有些拆东墙补西墙的感觉），如今终于被.NET3.5“名门正娶”，且不论集成的是不是时候，至少对于AJAX 在Web Form上面的应用算是一个里程碑。并且，对于MVC的AJAX的开发也提供不少的便利（包括如果以后还有别的ASP.NET架构推出）。

HOW？

因为这里只讲ASP.NET MVC(CTP)，所以要知道MVC如何工作，这里最好就是引用Scott关于MVC的一些操作实例和解释：

ASP.NET MVC Framework (Part 0): What is it?

ASP.NET MVC Framework (Part 1)

ASP.NET MVC Framework (Part 2): URL Routing

ASP.NET MVC Framework (Part 3): Passing ViewData from Controllers to Views

ASP.NET MVC Framework (Part 4): Handling Form Edit and Post Scenarios

Scott Hanselman's ASP.NET MVC First Look Screencast

TDD and Dependency Injection with the ASP.NET MVC Framework

Writing Unit Tests for Controller Actions

如果大家喜欢看中文的话这儿有Scott博客的翻译：http://blog.joycode.com/scottgu/

由于上面的文章篇幅比较长，具体的内容我在这里就不重复。关于使用过程中，上面文章中没有周全的、需要特别注意的要点、其他文章谈到的一些问题以及我前一个多星期总结出有一些问题，拿出来与大家共同探讨。（有些MVC目前的缺点我在之前的文章中也总结过，大家可以作为参考：使用微软ASP.NET MVC Framework的一些感受 + 收集园子朋友发现的bug反馈以及使用微软ASP.NET MVC Framework的一些感受 + 收集园子朋友发现的bug反馈【补充】以及MVC Toolkit 部分已发现bug的根治方案 Part(1)）。

如果有疏漏或者错谬的地方，欢迎大家指出。

首先来说一下MVC的特点（或者说不同之处）到底在哪？是在开发（维护）还是在应用？如果两者都有，最主要的是哪一方面。

关于开发。

ASP.NET MVC(CTP)结构图

很多人“吹捧”MVC能如何提高开发效率，我觉得是曲解了”MVC”架构的本质并且对Web Form的认识有点不足。事实上MVC的开发远没有很多人想象的那么“轻松”，他确实是”M-V-C”的“简单”组合，但是在开发的时候，你会遇到很多你在Web Form中不太容易“享受”到的“苦恼”（当然这些苦恼多半出于思维、对开发对象的认识以及编程习惯）。我先从一个浏览者操作的角度，简要说明一下MVC的C-V是怎么工作的，然后谈对应的开发的“痛并快乐着”（M层涉及的内容较多，Scott也已经做了比较多的说明）：

最普通的Web Form情况下当你打开浏览器的时候，你会通常进入的是一个类似这样的地址：http://www.cnblogs.com/,这时候，IIS的默认首页设置会把你带到比如这么一个页面：/Default.aspx，这个/Default.aspx是现实存在的，并且你是可以通过修改文件名直接访问对应存在的网页的。而在MVC模式下，你同样进入这样一个地址：http://MVC.cnblogs.com/，在新建好的ASP.NET MVC Application默认状态下，服务器首先找到的是这个路径：/下面的这个文件文件：/Default.aspx，但是你看到的内容却不是/Default.aspx，而是/Views/Home/Index.aspx。默认情况下/Default.aspx内容为空，只是起到URL识别作用，并且这个文件的内容不被实际访问，在Default.aspx中默认有这么一行说明：

这个文件的存在只是为了让IIS访问网站根目录/时，自动转向指定网页（我这里先说是网页，过会会说到，其实并非直接转向“网页”）。

让我们来看一下是怎么从/Default.aspx到/Views/Home/Index.aspx的。这个工作由C-V层协作完成，我们还要看一个十分重要的文件：/Global.asax.cs。打开之后我们可以看到这样一段代码：

            RouteTable.Routes.Add(new Route

            {

                Url = "Default.aspx",

                Defaults = new { controller = "Home", action = "Index", id = (string)null },

                RouteHandler = typeof(MvcRouteHandler)

            });

Url = "Default.aspx"，表示了一个URL传入条件（格式），即当传入文件名为/Default.aspx时。

Defaults = new { controller = "Home", action = "Index", id = (string)null }中，Defaults表示了当URL符合条件时，采取对应的操作，controller是C层的一个控制模块，“Home”对应了C层的HomeController类，其对应到的文件夹是V层中/Views/Home文件夹，这些对应都是自动完成的，你可以把这个”Home”间接理解为映射到/Views/Home/文件夹下面，但并不是直接访问，而是通过了C层的HomeController。Action字段负责传入需要在controller对应模块下，执行的操作命令，我们打开/Controller/HomeController.cs可以看到这一段：

  public class HomeController : Controller

    {

        [ControllerAction]

        public void Index()

        {

            RenderView("Index");

        }

        [ControllerAction]

        public void About()

        {

            RenderView("About");

        }

}

这里我们看到了public void Index ()这段代码，而Index就是上面/Global.asax.cs 中Index对应的“Index”。也是自动对应的。我们继续看这个Index()做了些什么：

RenderView("Index");

RenderView的第一个参数表示需要指向的页面，”Index”自动对应于Index.aspx文件，而我们刚才说了，这个HomeController是自动对应到/Views/Home文件夹的，那么整个Defaults = new { controller = "Home", action = "Index", id = (string)null }，我们就可以理解为：在HomeController内，运行Index()，而RenderView("Index")又将返回的网页指向Index.aspx,由于HomeController对应了/Views/Home文件夹，所以整个返回的结果就是：/Views/Home/Index.aspx。其中的id = (string)null一般都要涉及到数据操作（和M层有关），我们这里先不谈。

现在V和C之间如何对应连接起来，的我们应该已经了解了大致方法了，并且所有它们之间的数据传递等操作，都是以这个为基础的。

其中有一点一定要注意：不能把controller = "Home", action = "Index"直接理解为指向/Views/Home文件夹下面的Index.aspx文件，Index.aspx文件是由HomeController下面的Index()指定的，如果Index()指定的是RenderView("others.aspx”),那么controller = "Home", action = "Index"就会返回/Views/Home下面的others.aspx。

马上来总结一下这个过程相对于Web Form开发来说复杂在了什么地方：

首先直观的我们就能看到他会增加许多原本Web Form不会产生的代码文件（我们刚才还没涉及到Model层），可以说Controller中，几乎每一个Views中的文件夹，都需要我们去建立对应的xxxController.cs（/Views/Shares文件夹一般不需要）。并且这些工作相对来说是“额外”的——Web Form中你什么都不用做，就能直接访问/Views/Home/Index.aspx。（默认MVC方案建好之后我列举的这些代码会是为你自动生成的，但是你要继续开发，就必须自己增加了）。当然，这样做也是极具意义的，它让View层和Controller层分离开来，当你访问一个URL的时候，你其实不是在直接访问文件，而是在访问一个方法，由这个方法去确定到底返回哪个页面（也就是说在用一个不变的URL下面，根据不同的条件，可以返回不同的页面，这和Response.Redirect()有本质区别，光就表面效果看起来有点像整页的Excute()）。可能你还发现了，所有的调用过程中，几乎都是用了字符串形式，这不论对于面向对象的开发，还是日后维护，都是很不利的（这不是MVC构架本身的原因，而是我觉得MVC CTP有待改进的一个地方）。我认为完全可以把aspx页面的类名比如Views.Home.Index作为一个对象传入，哪怕用一个类似.ToString()的功能自动获取（只是类似返回一个string的效果，让系统可以在编译时检查就行），这样开发效率和维护效率都会提高很多。不知以后的MVC在这方面是否会有改进。

很多人把Web Form的一些codebehind放到.aspx中，或者想办法避免PostBack之类的操作，并且在.aspx中使用服务器控件一同去完成，这样的方法能不能算MVC的思路呢？我觉得有点像，但我觉得并不理想（哪怕目前的MVC所用的方法我也这么认为）。原因很简单，因为这并没有完全使V和C更多地分离开来（至少还有更好的方法），换句话说，这种情况下，V并不是一个纯粹的“模板”（即便MVC本身并没有要求非要这样）。目前MVC使用这样的形势来创建一个TextBox(input:text)：

<%= Html.TextBox("PlateName", ViewData.PlateOne.PlateName)%>

我们且不论"PlateName"这样的指定形势是否妥当（实际上在这里我们也不是要苛求，我只是举例，因为目前看来总有一个地方需要这么使用）。后面的ViewData.PlateOne.PlateName我来解释一下：

ViewData是通过C层实例化M层中对应数据模板，并通过上面提到的RenderView()传入页面（ViewPage）的一个<TViewData>（具体内容在M层中指定），我们看到的PlateOne就是在PlateViewDatan内的一个实体（M层中用ORM自动创建），PlateName是该实体下的一个“属性”，可以间接理解为对应数据库中的一个字段（但现在已经面向对象，所以不能完全等同起来，取值相等而已）。

为什么我说这不是纯粹的“模板”呢？因为他至少还需要在执行美工的时候去关注这些实体的属性，这样使得原本分离开来的V-C似乎又“藕断丝连”。更“模板”化的做法，当然是用一个内部标准的字符串替代，比如”{$PlateName}”，然后在最后对应M层的模板，使用Replace等等手段，把这些标记替换成实体中的属性值。当然这样的方法可能需要使用到“庞大”的字典，但对于追求MVC本身价值的角度来说，这是不过分的，况且这样的做法在Web Form 就早已经被使用。

关于维护

如同MVC的开发一样，MVC的维护是必要使程序员面对更多的代码文件。不对，纠正一下，这里应该说“代码段”更好，而不一定是“代码文件”，甚至是比之Web Form可能是更少的“代码文件”。

因为MVC中，程序的维护主要集中在C和M两层上，前面已经介绍，C层文件我们可以理解为对/Views/中指定文件夹的操作（并不绝对），一个网站V层（即可通过Controller访问）文件夹的个数一般都比.aspx.cs文件少是毋庸置疑的。而M层的代码文件，又与数据源有关，通常平均下来，一个SQL数据库表，对应一到两个.cs文件（另外也会涉及到一些你自己编写的实体。或者当然你也可以分离出很多，而一般不需要。）。

从这点上来说，分工更加明确了：需要执行逻辑的，找C层对应文件（或者说类/板块），需要对模板和一些数据处理的具体事务进行维护的，找M层具体文件，如上面提到的PlateViewData以及对应实体。如此可以看出MVC结构在开发“繁琐”的表面上，带来的是更加清晰的思路和逻辑处理板块。

如果能够达到我刚才说的“V层理想的模板”状态，那么这个维护的便捷性就更不止体现在单个程序逻辑上面，并且M/V/C各板块的同时工作将更小限度地受到相互间的干扰。

与之对应，还是有一些需要克服的困难，比如“代码文件”的减少，并不能掩盖大量代码段的出现，一个Controller.cs中可能会出现若干个类似Index()的方法，这也确实是一个让人头疼的问题，所以如何协调整理和高效管理这些方法，可能将成为提高对应模块维护效率的一个重点。

关于应用

这里所说的应用不是单指终端客户的使用，也包括我们在开发过程中的一些体验和解决问题的思路。

由于MVC（CTP）的应用似乎还没有走上正轨，我本人也还没有完成系统的开发（目前我对MVC也是观望和期待更多一点，所以也不敢“豁出去”），我们就先找一些在Web From下面的例子，谈谈是不是在某些方面，MVC可以起到更好的效果。

前一篇文章中，我提到了作为大学毕业设计而开发的一个ACDS系统（只是毕业设计中的一个组成部分，大约占1/4），似乎引来了许多疑问，我也觉得这样模糊的解释不太具有说服力（引发了一些人的胡乱猜测，在此赔罪），现在我把它其中的一个最基层的功能——“建表”给大家演示一下，然后从中讨论一下如果使用MVC，会给这个系统带来些什么影响（这个系统原本使用的是ASP.NET2.0，Web Form开发）。

当然这里还有一点要强调一下，这个系统的开发（整个物流〈信息〉系统，不光指ACDS），是我对MVC更加期待的一个催化剂，我本人并没有舍弃Web Form的意思，并且认为Web Form是完全可以优秀完成的，毕竟这个系统也是用Web Form开发的，并且我比较满意。我只是在寻求一种针对类似开发需求，更加高效的处理放案（微观上，非直观上）。并且必须说明，这个系统的开发不能完全代表所有的企业级应用开发，只是展示冰山一角的应用，希望可以抛砖引玉，而不要引起大家的误解。

我录了一段演示录像，大家可以下载看一下：

ACDS系统中"建表"环节演示+粗略分析  [下载]

（我所要演示的重点不是在功能或者实现方法上，而是数据流程以及一些事务处理上）

另外录像里面有两句（至少我自己感觉到的）口误，在此纠正：

1、一个地方我说了PostBack返回的是“对象，或者说对象的值”，这里的“值”说成“属性”更恰当。

2、有个地方我说成了TextBox.MVC,应该是TextBox.Text。

由于时间仓促，没有太多准备，也来不及做更多论述。如果大家对视频里面我说的有疑问，可以单独列出，我们展开探讨。

视频中的一张对于ACDS（建表环节/PostBack环节）的简易图