誰在生產應用程序中實際使用DataGrid / GridView / FormView / etc？

Question

如果其他人和我一樣感到好奇。 對我來說，控件如datagrid / gridview / formview / etc. 非常適合演示或演示。 要花時間調整這些控件，覆蓋它們的默認行為（掛進他們的愚蠢事件等）是一件非常令人頭疼的問題。 我使用的唯一控件是轉發器，因為它為我提供了最大的靈活性。

簡而言之，它們幾乎是臃腫軟件。

我寧願編織自己的html / css，使用我自己的自定義分頁查詢。

同樣，如果你需要拋出一個快速頁面，這些控件很棒（特別是如果你試圖吸引人們輕松進行.NET開發）。

我必須是少數，否則MS不會在這些類型的控制上投入如此多的開發時間......

Answer 1

任何認為沒人使用* Grid控件的人顯然從未在內部企業webapp上工作過。

Answer 2

我幾乎都在編寫自己的HTML - 我正在使用ListView和Masterpages，但實際上並沒有真正使用控件。 順便說一句，我的ListView嘲笑你那個愚蠢的老式中繼器。

但是，英國媒體報道不一定是件壞事。 如果我需要構建一個低容量的Intranet應用程序，我寧願付出一個經驗不足的開發人員拖放控件而不是HTML twiddler（像你或我）來制作每個標簽。 這里有一個快速，簡單的方法。 只要基於控件的代碼以可維護的方式編寫，那么在這種情況下“bloatware”的成本是多少？ 通常布線控制需要較少的自定義代碼，這意味着簡單的維護。

我不得不反對你的一個地方 - 幾乎不管應用程序 - 都在制作你自己的分頁查詢。 你可能喜歡這樣做，但它絕對沒有商業價值。 有幾種專業級DAL工具通常會編寫比大多數開發人員更易維護，更快速的查詢。 即使您精心制作完美的分頁查詢，它也無法及時更新架構，除非您繼續花費數小時的時間。 我認為更好地利用這些時間是建立一個輕量級系統，並將這些時間用於監視和修復特定的瓶頸，而不是立即跳轉到“數據庫匯編語言”層。

Answer 3

我一直在讀你的帖子，這讓我感到愚蠢。

我的意思是在我工作的每個應用程序中，其中至少有一個datagrid / gridview。 而且我沒有感覺我錯過了什么。

當然，我發現datagrid / gridview有點臃腫，但是它們使用起來有多惡心嗎？

Answer 4

我認為在你譴責它們之前你需要學會使用GridViews。 我廣泛使用它們。 起初，弄清楚某些事情有點挑戰，但現在它們是不可或缺的。

使用AJAX CRUD和分頁的UpdatePanel中的GridView很快。 以這種方式設置的較大系統之一（用於內部/外部應用程序）在后端具有適度大小的數據庫。 有許多nvarchar（2000）字段，轉換和更新都很棒。

無論如何，如果您編寫了自己的顯示數據版本，則可能需要繼續使用它。 （可以用來編寫自己的編譯器，編寫自己的HTML版本，編寫自己的數據訪問二進制版本......）使用GridView的優點是有很多人熟悉它並且MSFT已經抽象/建模了這個類來做很多我們以前必須手動完成的事情。

Answer 5

我們公司開發的每個應用程序都有網格（應用程序都在防火牆之后）。 這包括Web應用程序和Winform應用程序。 對於網絡應用程序，它是我們使用Janus網格的winform應用程序的自定義排序的良好網格視圖。 我試圖讓開發人員/用戶想到更好的用戶界面，但這很難改變。 我必須承認它仍然比使用Access構建他們的“自己的”應用程序的用戶更好，然后我需要支持！

Answer 6

使用像GridView這樣的控件非常適合簡單的應用程序。 即使你是一個服務器端的HTML支架 - 笨拙的忍者，他們也可以使開發簡單的東西更省時。 問題是他們通常最終會開始暴露他們的缺點，最終你不得不花時間調整它們。 但至少你可以起床並快速開始。

例如，GridView中的默認分頁不支持數據庫本身的分頁（您必須先加載所有行才能分頁），所以一旦開始感覺性能不佳，您可能需要考慮滾動你自己的，或者更好的是，找到一個更有能力的網格控制。

無論如何，重點是預先構建的組件是好的 。 他們幫助。 但像往常一樣，這取決於你需要他們做什么。

Answer 7

我實際上廣泛使用GridView作為管理控制台。 我甚至創建了一個自定義DataFieldControl，它根據數據字段設置字段的標題文本和排序表達式，在底部創建一個Insert行並自動收集行中的值並將它們轉發到數據源的insert方法，並生成一個列表框如果指定了其他列表數據源。 雖然投入巨大的時間投入，但它確實非常有用。

我還有另一個控件，當沒有記錄時（在EmptyDataTemplate中），它將根據字段的元數據生成一個新的數據表單。

<asp:GridView ...>
 <Columns>
       <my:AutoField HeaderText="Type" 
                      DataField="TypeId"
                      ListDataSourceID="TypesDataSource"
                      ListDataTextField="TypeName" />          
  </Columns>

    <EmptyDataTemplate>
        <my:AutoEmptyData runat="server" />
    </EmptyDataTemplate>

</asp:GridView>

Answer 8

我非常喜歡telerik radgrid。 他們的產品並不便宜，但你可以獲得很多控制和功能。 並且數據綁定支持非常好，無論是在簡單的asp.net數據源綁定方式還是在更自定義的handle-your-own-databinding-events方式中。

Answer 9

在我的公司，我們到處都使用網格，主要是ComponentArt Grid（ http://www.componentart.com/ ）。 是的，它是英國媒體報道軟件，但是你獲得了很多重新發明的功能：排序，分頁，分組，列重新排序，內聯編輯，模板化（服務器端和客戶端）。 客戶端API也很好。

Answer 10

我喜歡GridView控件，並在我公司網站的幾個自定義DotNetNuke模塊中使用它。 首先，使用內置控件意味着更少的依賴性需要擔心。 一旦我設置了我想要它的方式，我基本上將代碼復制到其他頁面，只需要做一些小的調整。

我發現現代網格控件（Infragistics，T​​elerik等）有很多選項，配置網格需要的時間比其他任何東西都長。 MS控件非常簡單，但它們幾乎可以做任何事情。

Answer 11

它們是asp.net的好處之一。 直到最近我才討厭它們，但是一旦你了解了哪些設置必須改變哪些實例，你就越容易使用它們。 主要是我喜歡表單視圖和列表視圖，gridview仍然需要一些工作。

Answer 12

GridView / FormView / DataGrid等組件遵循80/20規則。

這意味着，當您將它們用於簡單目的時，有80％的時間可以完成工作並且非常容易實現。

但是，有20％的時間你會嘗試構建復雜（或奇怪）的東西，並且你將被迫跳過十幾個箍並以多種方式彎曲代碼以嘗試實現解決方案。

訣竅是要知道問題是80問題還是20問題，如果你能早點發現問題，那么你最好自己從頭開始編寫代碼並放棄“省時”問題。

Answer 13

對於我的企業內部網項目，網格是必不可少的。 它們是在ASP.NET webforms平台上輕松報告的基礎。

易於設計在網頁上粘貼網格。 插入BoundField對象以進行簡單綁定。 asp:HyperlinkField ，便於鏈接。

捆綁

您可以通過以下幾種方式綁定網格：

• 對象集合（ List ， ArrayList ， Hashtable或任何簡單集合）
• 代碼隱藏中的SqlDataReader （yikes，在您的表示層中需要SQL）
• SqlDataSource （指定存儲過程。結果集上的所有列都直接映射到網格的列。如果報告不能很好地模仿您的域對象，那么這是非常快速和骯臟的。即不同事物的總結。）
• objectDataSource（綁定到BL上的方法）

對於那些可能調用SqlDataSource和ObjectDataSource ，您並不總是必須在.aspx.cs或.aspx.vb中聲明它們。 我不是在這里提倡他們，只是指出可能性。

我認為您不能忽視內置GridView和其他第三方網格的RAD優勢。 管理類型喜歡並希望獲得表格數據。

Answer 14

我們在Intranet應用程序上使用Infragistics UltraWebGrid + LinqDataSource。

它為我們提供了ajax，排序，過濾，分頁服務器端。

“export to excel”也是一個殺手鐧。

我們有5000多個用戶，大量數據，性能非常好。

Answer 15

一旦我從用戶故事開始設計，而不是從數據庫表要求開始設計，我基本上放棄了網格。 從來沒有可編輯的網格。 舊的方式就是我們如何強迫用戶為我們的系統進行數據輸入/表格維護，它從未與他們的工作流程相匹配 - 任何真正的工作最終都會從一個主/子表單跳到另一個。

用戶從來沒有想過 - 但他們肯定知道我們的應用程序比應該更難使用。

分析應用程序是一個例外。 但是這些相對較少，而且它們基本上是只讀的。

Answer 16

我在我工作的公司環境中廣泛使用它們，而我現在正在使用它們。 那些不使用它們的人讓我想起了那些“我用記事本建造它”的開發人員。 如果你不打算節省時間，那么使用asp.net有什么意義呢？

Answer 17

我也想看看為什么GridView等被認為是“膨脹軟件”的擴展答案。 我已廣泛使用GridView以及第三方產品（Telerik等），並發現對於大多數內部和一些外部項目，它們運行良好。 它們快速，易於使用，可定制 - 而且最好 - 我可以將它們交給知道GridViews的人，然后他們可以輕松地從我離開的地方拿起。 如果我手動編寫所有眾多應用程序/控件的代碼，那么即使在最好的情況下，下一個人弄清楚發生了什么的開銷也是巨大的。

對我來說，我可以看到一些第三方產品是英國媒體報道軟件（但有時候仍然有用），但是我發現使用溫和的查詢，我覺得它很快。

Answer 18

我之前從未真正使用過標准的WinForms網格，但在我上一份工作中，我們廣泛使用了ComponentOne FlexGrid並且工作得非常好。 嘗試獲得我們想要的所有定制仍然有一些煩惱，但總體而言，它為我們節省了大量時間並產生了美好的結果。

目前我正在使用Silverlight 3和RIA Services，我無法想象在沒有DataGrid和DataForm控件的情況下嘗試生成我們正在做的事情。 節省的時間遠遠超過任何開銷。

Answer 19

很長一段時間我都很想知道這件事。 這里似乎有一個共識，即網格控件是英國媒體報道。 但是，任何人都可以明確地引用使用這些控件的成本嗎？ 是否有過多的HTML發送到瀏覽器？ 服務器上的資源太多了？ 是否更快地生成HTML表（假設它編寫得很好）？

除了英國媒體報道軟件問題之外，當UI要求得到增強以包含超出標准控件范圍的功能時，我經常會擱淺。 例如，在早期的ASP.Net版本中，我努力將圖像放在列標題中。 並且，我認為添加跨越多列的第二個頂級標題行仍然是一個挑戰。 在某些時候，與控制器搏斗以實現期望的效果變得非常困難。 如果你知道你想要的HTML，那就太令人沮喪了，但是你無法讓控件做到這一點。

在一個項目中，我終於放棄了自己寫了一個HTML表類來生成一個非常復雜的網格。 它花了幾天時間才恰到好處。 但是，現在我已經掌握了基本代碼，並且為將來的網格進行調整會更有效率。

但毫無疑問。 如果您能夠在他們的限制范圍內生活，那么很難擊敗花哨的網格控件以實現快速開發。

Answer 20

我從來沒用過它。 我完全同意，這是英國媒體報道。 我通常最終使用轉發器和我制作的自定義控件。

Answer 21

對於任何長期而言，我會盡量避免使用datagrid / gridview，它有時變得過於hacky使它完全按照你的意願行事，經過一定數量的調整后你開始意識到從長遠來看它不會節省時間你可能不會控制您需要的標記。

然而，內置的分頁和排序功能運行良好，並在2008年有一個新的ListView控件，旨在解決其中的一些問題，並讓您更嚴格地控​​制輸出的html。

Answer 22

如果你在面向公眾的網站上與設計師合作很多，那么你應該放棄GridViews並堅持使用轉發器。 無論如何，這是我的意見 - 為了滿足設計要求，我不得不拆開數百個GridView並將它們變成簡單的中繼器。

如果你在面向公眾的網站上使用10英尺極點的DataGrids或GridViews附近，那么你必須使用CSS友好的控制適配器。 （此時您可能會發現在Repeater中執行它更容易。）在控制適配器可用之前，我會認為這些控件是開箱即用的。

我發現有太多的.NET開發人員對設計，可訪問性，CSS，javascript，標准等沒有很好的理解，這就是他們屈服於GridViews，ObjectDataSources等的原因。

Answer 23

GridView是一個很好的，非常強大的控件，適用於CSS或主題。 令我討厭的唯一一件事是，當舊的1.1 DataGrid被asp.net 2.0中的GridView替換時，VirtualCount屬性被刪除，並且它對於實現自定義分頁很有用。 但是可以通過數據適配器完成相同的操作
盡管使用中繼器可能更清晰，並且您可以完全控制渲染的html，但我仍然不建議采用這種方式，因為更難實現和維護。

Answer 24

只是閱讀你的帖子。 我同意PHP比asp更容易。 但我剛開始使用visual studio進行表單和網格視圖。 無論是vb還是C＃程序員都無法輕松搞定。 ASP上傳大文件時仍然存在問題。 PHP它很容易。 我在IIS 7.5下運行PHP

Answer 25

我是一個中等水平的開發人員，我可以說沒有這些控制，我無法學習開發。只有你自己承認它一段時間，直到找到你的方式來定制它，最終的結果將是偉大的

Answer 26

我試圖在上下文中看一下。 我有一個頁面有一個很好的gridview（一次顯示10行，6列，排序和分頁），如果我只是看看與viewstate一起創建的html表，我只看到29k的代碼。

使用轉發器或列表視圖的29k對18k真的值得在這些寬帶時間內付出所有努力嗎？

我個人堅持使用gridviews，但我工作的設計人員有時會抱怨試圖通過CSS設置它。