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