WebForms之我见

  
  　　既然Web应用瓶颈大都在数据库访问上，那么一般该如何解决这个问题呢？最直接的方式应该是优化数据库的查询，但是最关键的可能还是缓存。君不见每个谈到Web应用性能优化的讲座都将Cache放在数一数二的位置上，因为这的确是最有效的优化方式之一。在一个并发较高的Web应用中，对一些数据进行1分钟的缓存也能带来相当可观的性能提高。其他的方式可能还有生成静态页面（没有比这访问速度更快的了），异步调用（例如一篇刚发布的文章，在数分钟后才能被搜索到也没有关系，那么何必一定要同步地、即时地写入数据或者创建索引呢？）、分离不同作用的服务器（可以为不同服务器进行有针对性的配置，例如分离图片服务器），做Web服务器端的负载均衡（stateless的重要性由此可见），对数据库进行纵向切割（加快内存中载入的数据量可以提高查询性能，并且纵向切割后能够使用多台数据库服务器分担压力），横向切割（sharding，将数据分置在不同的数据库中，以此可以通过scale out来扩展减少每台服务器的负载，提高性能），作数据冗余或Master-Slave（稍稍降低写操作的性能而提高读取数据的性能，普通Web应用大都“读取”远多于“写入”）等等。
  
  　　当然我上面提到的都是应用程序实现和架构方面的东西，事实上开发一个高性能Web应用还涉及到硬件/软件/操作系统等多方面，这里就不多解释了（其实这方面我也还在探索过程中）。其实我在这里想说的仍然是，开发高性能Web应用程序的关键大都与具体所用的实现技术无关：只要“实现”正确，做法大都相同，无论Sql Server/Oracle，Windows/Linux还是ASP.NET/RoR，其本质都差不多。Ruby和C#的性能相差十倍（存疑，求证），不还是能够开发出高性能的Web应用吗？

没想到我的文章引起了那么大的反应，看来最近MVC框架的确是一个热门话题。正如上一篇文章开始所说的，我不会对MVC框架有任何“贬低”，任何技术滥用都有问题，所以任何东西都会有所谓的Best Practice（去MSDN的Patterns & Practice栏目看看就知道了）。我写这几篇文章，是想说明，很多WebForms的缺点是被夸大了。WebForms的确有缺点，但是我们完全可以避开，并且仅仅利用到WebForms给我们带来的便利。这其实也是一种Best Practice。相信以后MVC框架也一定会出现这样的东西。
  
  　　在上一篇的评论中，有朋友说我是“边缘”的ASP.NET程序员，大概是因为我用WebForms但是抛弃ViewState、PostBack和GridView这种“重要”的东西吧。我不知道这样是不是“边缘”，但是我的确抛弃了不少东西。例如还有ADO.NET中的DataSet/DataTable——但是我们还有DataReader呢！抛弃了微软提供的一部分东西，我们其实可以发现，.NET里的基础组件一个都不少，用起来也会得心应手。
  
  　　去其糟粕，取其精华。
  
  三、生成丑陋的HTML，难以进行样式控制
  　　在ASP.NET的WebForms刚出现时，各种“演示”看上去真的很美。这个特点微软至今还保留着，各微软技术大会上的演示真的让人感到心潮澎湃。在我看来，那些“激素大会”更是一种推广策略，而并没有将目光集中在技术细节的本身。所以微软的东西似乎总是有入门容易提高难的“毛病”。开发人员被“宠坏”了，上一篇文章中有位朋友说这就是“穷人的孩子早当家”，还是有一定道理的。在.NET环境下我们就像是官宦子弟，不过这并不能成为我们习惯于“吃喝嫖赌”的理由。我们要合理利用富裕的环境带给我们的资源，但是要适当地抛弃一些不好的东西。
  
  　　好像说了几句废话，现在进入正题。说到WebForms则不得不提丰富的控件，基于ASP.NET平台的第三方控件提供商似乎比其他平台下的总合还要多，这也是产业阿。在微软提供的控件里，GridView（或者1.1里的DataGrid）是被“演示”次数最多的，也似乎是最强大（还是差不多等同于“复杂”）的。有了GridView之后，很多开发人员就习惯于朝页面上拖个控件，然后再设计器里点点鼠标，设设样式，最后绑定一个DataTable上去。哗，好一个表格就此诞生。然后我们还可以响应其事件，对某一行数据进行编辑，删除。太轻松了，这世界一下子变得美好了起来。不过由于GridView过于“强大”，它几乎成为了ASP.NET初学人员的必修课，当对于Web开发都不明就里的初学者都习惯于GridView、GridView、GridView时，它的滥用也就不可避免了。于是乎，做表格，用GirdView，做列表，也用GirdView（不就是个只有一列的表格嘛）。
  
  　　可惜的是，GridView有很多毛病。如果要使用GridView的高级功能（添加、修改、删除等等），ViewState必不可少，再加上很多开发人员在绑定数据时没有经过筛选，导致ViewState变得无比庞大（例如显示一个文章列表，明明只需要ID、标题，创建时间等基本信息，却用一个“令人无比愉悦”的SELECT * FROM Article语句把文章内容也选择了出来并绑定在GridView上，ViewState中也就不得不包含几千几万字的多余数据）。
  
  　　不过现在想说的，倒是它生成出的HTML。
  
  　　GridView在客户端生成的HTML是个<table />，可惜这个<table />里东西太多了，的确显得很丑陋。不过更关键的在于，这个表格的样式实在难以控制。虽说GridView里从标题到单元格到低部都能够进行样式的定义，但是灵活度还是远远不够。再加上GridView生成的HTML死板而不符合Web标准（例如不会生成<th />标签，用ControlAdaptor进行改造的做法不算），但是优秀的样式开发人员大都是坚定的Web标准支持或推广者，ASP.NET对于标准支持不佳，难以控制样式的说法满天飞扬。
  
  　　我想为WebForms喊冤。不过首先我会打倒以GridView为首的复杂控件（包扩DataList、FormView等等）并狠狠踩上几脚。有人说，当抛弃了GridView之后，用WebForms还有什么意义？其实类似的话也不断在我说要抛弃ViewState和（复杂）的PostBack时出现。如果您觉得抛弃了这些东西WebForms就失去意义的话，那么我想说，ViewState、PostBack、GridView远不是WebForms的全部。我认为，Control模型（或者说组件化模型）才是WebForms的关键。而这个模型的“基础”是绝对优秀的。下面我会进行一些展示，虽然这些展示我觉得是基础中的基础。

（编辑：IT资讯之家 www.it55.com）