大家知道在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() 特性來工作
