2009-08-25 27 views
3

我正在使用ASP.NET MVC應用程序。如何在ListBox中加載大量數據? ASP.NET MVC應用程序

要求用戶能夠從列表框中選擇一個可能包含超過30,000個條目的項目。

是否有一種動態的方式來使用Ajax調用來填充此ListBox的內容 - 這會表現出色嗎?

如果只是在服務器上填充ListBox控件,然後讓用戶等待頁面呈現30,000個條目時,我會更好嗎?

如果我採用某種jQuery解決方案,性能會更好嗎?

關於如何最有效地處理這種情況(無需客戶更改要求:-))的任何建議?

+0

類似的問題:http://stackoverflow.com/questions/1258689/asp-net-javascript-loading-huge-data-in-browser/1258727 – 2009-08-25 12:47:21

+0

發送你的客戶鏈接到這個線程和http:// homepage.mac.com/bradster/iarchitect/controls.htm 我的賭注是,他的應用程序在該網頁中有更多的屏幕截圖... – voyager 2009-08-25 12:47:46

回答

9

這聽起來像個壞主意 - 30,000個條目?如果你必須從列表中選擇這個尺寸,你會有什麼感覺?

對這種類型的用例最好使用自動完成功能。

+3

+1自動完成/建議最佳路線 – redsquare 2009-08-25 12:36:44

+0

插件:http://bassistance.de/jquery-plugins/jquery-plugin-autocomplete /是我用於大型商業系統自動填充大量條目的工具。 – Kezzer 2009-08-25 12:38:27

+0

+1對於沒有使用30K條目的列表框。 – BigBlondeViking 2009-08-25 12:39:28

3

這個問題的唯一答案是:不要。你有沒有嘗試從列表框中選擇30,000個項目的東西?客戶有沒有這樣做?

更新:我認爲最有效的解決方案是通過電子郵件發送此頁面的鏈接給您的客戶,讓他感受到這個問題引發的普遍恐懼。

+0

大聲笑!就像我說的。我同意你的觀點。只是想絕對確定我沒有看到什麼。 – jsteele 2009-08-25 12:44:26

0

如果預先加載所有內容,性能只會降低下載標記並初始渲染時的速度。

如果您通過AJAX調用(jQuery或其他方式)加載所有內容,它將不得不提出請求,下載結果,解析結果並將它們呈現到頁面......這更慢(特別是對於大小的東西)。

我會問爲什麼ListBox需要這麼多條目。沒有用戶將能夠有效地使用該控件。也許減少列表的大小和實現分頁,使事情更有用一點?

1

聽起來像一個完整的瘋狂。

用戶如果需要翻閱30000個條目,會感覺如何?另外,對於眼睛不完整和運動技能稍差的用戶來說,精確操作鼠標的經驗會很痛苦。

不要這樣做。使用其他方法:

  • 內容分頁,任選複選框選擇根據各種標準
  • 羣歸類選項
  • 排序的內容項用戶首先選擇合適的類別,然後從短選擇選項列表
  • 如果精確選擇並不重要,嘗試使用Ajax技術,以顯示與建議列表中選擇從
  • 添加過濾器領域,爲用戶定義圖案,並讓其他人只是離席

您的另一個想法是使用支持多列和圖標的增強列表。看看Windows資源管理器。從具有大圖標的幾列中選擇要比從一小串細小文本字符串中選擇要容易得多。

您的方法的另一個缺點:在選擇列表中同時擁有多條記錄也會將頁面大小擴大到幾兆字節。如果您啓用了視圖狀態,則會非常緩慢且耗費資源。

+0

我同意上面的所有意見。我們正在轉換一個現有的應用程序,它有一個ListBox和30k +項目。儘管我們有相反的建議,但客戶仍然希望保持這種行爲。我想確保我沒有忽視某些東西。 – jsteele 2009-08-25 12:37:59

4

我不會試圖回答這個爲someone else already did

這種類型的控制被認爲太 經常在企業應用程序: 下拉控制,並列出 包含數千個條目。誰誤用它 普遍得到暗示,這可能是

Some programmers just use a hammer for screws. http://homepage.mac.com/bradster/iarchitect/images/list2.gif

程序員 不合適時,他們發現, 它需要一個非常長的時間 加載形式。

以下 消息,在Visual Basic程序員 論壇上張貼 1996年12月11日,是典型的:

我要填寫一個 列表框2000項......這 令人難以置信的需要長...超過20分鐘。有任何想法嗎?

與其它投 於1996年12月16日,是有點少 典型:

我正在尋找一個列表 框控件,可以...舉辦大型 數量的條目(20000 + )

這種笨拙的控制 的藉口往往是 全能呼叫誤導解釋武器,「我們必須 保證數據的完整性。」 程序員想要確保 用戶指定一個有效的條目;在他們的 視圖中,執行此操作的最佳方法是 強制用戶從列表中進行選擇。 如果您在 列表中顯示20, 60或甚至100個項目,那就沒問題了。除此之外,事實 用戶每次只能滾動一個 少數項目導致控制變得笨拙。

想象一下,如果您的硬盤上沒有文件夾和 目錄。 無論何時您需要指定一個文件, 您都會看到一個下拉列表 控件,其中包含您的硬盤上每個 文件的名稱,並要求您選擇要打開的文件 。幾乎沒有 人,包括程序員, 考慮這樣的方法,因爲任何東西都不是完全不可接受的。

的所有數據都可以在一些 有意義的方式,將允許用戶 更迅速地訪問 特定信息來組織他或她是 感興趣。文件組織 到文件夾或目錄的 例子。員工通常根據部門,職位, 或工資等級分類爲 。設計 接口來利用適當的組織將允許用戶更快速地找到所需的信息,同時,「確保數據完整性」,同時, 。

0

從性能角度來看,30,000個項目實際上並沒有那麼多。嘗試一下,在測試中,我已經能夠放置100,000件物品。

從用戶角度來看,儘管如此,我認爲絕對最大的1,000個項目可能是可用性視角的限制。我通常停在100件物品上。我建議在列表框上方添加一個文本框。允許用戶搜索條款。您可以使用jquery來填充框或使用更新面板。如果將結果限制爲100個項目,這將非常快速。

0

只是使用一些很好的老式驗證;不需要宇宙中每個已知選項的瘋狂列表框。

相關問題