对ASP.NET 2.0下面的新控件的困惑

核心提示：大家知道在asp.net2.0下面微软件给出了一系统的新控件，有一些是挺有用的，对ASP.NET 2.0下面的新控件的困惑，比如那个Membership成员管理系统，以及分步向导控件都为我们节省了很多的时间，关于大数据分页的问题今天在网上看到了一个老外的东西好象挺有意思的，近期我会抽一些时间翻译出来奉献给大家，而另外一

大家知道在asp.net2.0下面微软件给出了一系统的新控件，有一些是挺有用的，比如那个Membership成员管理系统，以及分步向导控件都为我们节省了很多的时间，而另外一些，比如从Datagrid上升级来的Gridview有时候感觉倒不是那么好。

这个控件在为我们提供很大的方便的同时也失去灵活性，比如直接指定一个SQL语句就可以完成数据访问的工作，而分页显示，排序更是比吃饭还简单。众所周知，这是与我们分层的逻辑架构设计相违背的，这样就造成了一个难堪的局面，新手很难单单只凭借这些控件做出功能强大而完善的程序，更要命的是，它封装了很多的操作，而我们并不清楚它在后台是怎么运作的，对于新手来说，万一出了问题他们根本不知道问题出在哪里，而有经验的程序员肯定不会采用如此难看设计。要用它完成升级等操作的时候我们会要求对输入的内容进行验证也比较不方便，而该控件运行时会生成庞大的ViewState字段造成效率下降，至于在大数据量下面的分页性能就更不用说了，虽然现在可以把DataSet作二进制序列化，但是结果仍不尽人意。那么我们就要问这样的控件存在的价值到底在哪里呢？

GridView虽然可以做分页，但是它提供的分页样式也就那些，如果要手动定义很麻烦。话又说回来，如果需要非常强大的数据操作，比如多列排序，汇总，导出，合计，甚至拖放等等复杂的功能还不如借助其它的手段来实现，比如商业控件和使用智能客户端平台更方便一些。GridView的数十个样式属性的设计也是很糟糕的，虽然你可以用这些属性做出非常花里胡哨的用户界面，但是一旦一个项目有数十个GridView的时候要修改的工作简直不可想象，所以，我们还得借助CSS这样强大的工具来定义它的样式的。

同样鸡肋的还有那个SQL数据源控件，把做程序弄得如此简化，虽然在大型项目里面没有什么实用价值，我觉得还是有一定的好处的，至少它可以提高对编程感兴趣水平又不高的人的信心，想当年我正是瞎子摸象般用DW的自动编码功能做了个个人网站出来玩，虽然它生成的代码是那么的难看，逻辑是那么的混乱，后来我还凭借满腔的热忱投入到编程当中，否则我也不会走到今天了。

我比较看好的是那个叫做ObjectDataSource的数据源控件，为什么呢，它可以在后台自由地控制程序逻辑，让每一步的操作都很透明，加上利用泛型提供的强大特性让我们的程序看起来感觉不错。而数据源为我们前台数据绑定工作节省了不少的时间，好好的利用这一特性可以为我们的程序带来很多的便利。

熟悉微软的StarterKit的朋友都知道里面有一个个人网站的示例程序，就是对象数据源应用的很典型的例子，在这个程序中可以说是把ASP.NET2.0提供的新控件特性发挥到了淋漓尽致，用少量的代码就完成了很多的逻辑工作。但是它毕竟只是个人的站而已，很多地方的工作做得还很不够，比如说我可以提交一个空的表单，它并不作任何的检查等。

总之，这些新控件合理利用还是会大大提高效率的，并且也给了编程水平不高的朋友们一个C#锐利新体验的机会。从功能上说个人认为比DW那种三脚猫的伎俩好多了，好多人还在讨论在DW下面如何编程，实在有些不妥，DW更适合做界面一些。

关于分页的问题，我最近正在做一个ASP.NET 2.0下面的分页控件，总体上讲是从1.1里面MSDN SQLPAGER基础上升级改造过来的东西，一是程序上到2.0的迁移，二是做成了用户控件的形式，这样分页的样式可以根据自己的喜好自由扩展，并且可以使用微软的最新企业库的数据访问块进行与数据库的通讯，可以使用数据缓存或者只读取需要的记录，提高了效率。目前已经基本完工将在新日发布，欢迎大家关注。同时由于自身水平与精力有限，难免有一些不足和缺点，不过大家放心，这个控件开发源代码，您可以对它进行自由 的扩展，要是有问题的话也可以从源代码排查修正。

关于大数据分页的问题今天在网上看到了一个老外的东西好象挺有意思的，近期我会抽一些时间翻译出来奉献给大家，这里是源文地址,大意是利用SQL SERVER 2005的 ROW_NUMBER() 特性来工作。