有沒有人在.NET中使用類型化的數據集？

Question

我曾嘗試在相對較小的生產應用程序中使用鍵入的DateSets。最初它看起來像一個不錯的主意，但結果卻不一樣。對於一些基本的任務來說，這很不錯，但是一旦需要更高級的東西，就會受到限制，並且失敗了。幸運的是該項目被取消了，從現在開始，我嘗試堅持一個像NHibernate一樣的適當的ORM。

但我仍然懷疑 - 它們是由於某種原因而創建的。也許我只是不明白如何正確使用它們？有人在那裏成功地在生產系統中使用它們嗎？

補充：

你能不能也趕緊解釋你是如何使用他們？

我試圖使用它們作爲我的DAL - 它是一個Windows窗體應用程序，並且它會從表中將數據從表中獲取到DataSet中，然後在調用TableManager的層次更新事物之前使用數據進行處理（不記得確切的名字）。 DataSet對每個數據庫的物理表都有一個表。當我不得不做一些像master/details關係那樣的事情時，問題就開始了，我必須一次插入一堆記錄（一個主記錄和多個詳細記錄）到幾個表中，同時保持外鍵正確。

新增2：

哦，如果你使用的是他們，你在哪裏把你的業務邏輯呢？ （驗證，計算等）

Answer 1

它們對我創建XML文檔以發送到Web服務非常有用。客戶端將預期的數據定義爲類型化的DataSets，這使得在內存中創建DataTable並獲取XML表示變得非常簡單。

現在，對於真正的數據庫訪問...我使用我自己的DAL，我同意你 - 數據集非常有限。

Answer 2

我正在使用它們。也許只是因爲我沒有嘗試NHibernate，但我不能使用LINQ，因爲我只限於Windows 2000，它不運行.NET 3.起初他們似乎很理想，但我發現了足夠奇怪的怪癖關於他們開始拒絕我。

Answer 3

我們始終使用鍵入的數據集，實際上我們將它們用作最佳實踐。我們這樣做的原因是在編譯時捕獲錯誤，而不是使用基於字符串的查找列名，這可能會在運行時引入錯誤。

我想，一如既往，這取決於場景以及您是否獲得使用它們的優勢。

的標準行參考：

oRow["row_pk"]

在類型化數據集，現在變成了：

oRow.row_pk

我們的數據集通常匹配數據庫scema，我們使用DataAdapters更新更改數據庫中使用存儲程序。輸出參數使用從數據庫生成的密鑰更新數據集。

很明顯，您需要按照正確的順序運行適配器更新，才能以正確的順序生成所有密鑰。刪除父/子行時還必須小心，並確保這些刪除按正確的順序進行以防止數據庫異常。

返回.NET時仍然是1.1我讀了一本關於ADO.NET by David Sceppa的書，這開啓了我的視野，讓我可以真正體會到什麼，並簡化了我的DAL（使用鍵入的數據集）。那裏有很多技術可以真正幫助改進你的代碼，我強烈推薦它。

Answer 4

如果您相信軟件編寫軟件的好處，以及靜態類型 - 軟件捕捉軟件錯誤 - 的代價，那麼它們正是您所需要的，但代價是複雜性（當然），開發開銷（可能）和效率（可能但是可爭辯的） - 這是C＃和java等語言的基本前提。

然而，這並不是一場完全獲勝的戰役。

編輯（請求解釋）：

複雜性。

使用C＃或java，你最終會得到很多配置，類型聲明，轉換，類型檢查和驗證的代碼。其中一些是你自己寫的，一些IDE是爲你寫的。但這是開發者負責的所有代碼。主要的好處是IDE /編譯器 - 指出可能的軟件錯誤和自動完成。我可以放心地說，沒有采取任何一方的行業討論，是否有代碼量的龐大數量是值得的。這至少明顯違反了YAGNI。在VS中，我通常會遇到由IDE編寫的整個代碼文件，它有一些缺陷，我最終需要弄清楚。我不喜歡搞清楚我沒有寫的代碼。

開發開銷。

同上。而且java對於所有需要編寫和維護的各種XML配置文件而言都是衆所周知的，它們可以使應用程序組合在一起。 RoR的很大吸引力是「按照慣例配置」，只是爲了避免這種情況。

效率。

與編譯語言相比，解釋或JIT編譯語言的效率非常低下的斷言早已被接受爲不言自明。由於比我有時間在這裏有更多的原因，這個假設正受到質疑;例如通過一些更新，更快的JavaScript引擎。

在這個網站上搜索的明顯的東西，谷歌的，是「後期綁定」，「動態類型」，「JIT編譯器」。

Answer 5

我使用它們，但不是通常意義上的。這是類似於ocdecio的答案，但在我的情況下，它在asp.net作爲一個演示模型（不包括表適配器）

的「客戶服務」層使用它們（作爲部分合同）的任何方法，該方法或返回數據。基礎業務服務使用更傳統的poco方法，客戶端服務只是做一些映射來爲給定的UI生成強類型的數據集。

工具支持使新開發人員（他們可以按照asp.net/learn視頻來加快速度）使用他們所需的服務，從而更容易。 UI構建者還可以快速「設計」他們想要檢索的一組新數據，並讓相關服務團隊從那裏開始。

Answer 6

我在以下情況下使用它們： 1）編寫一次性項目，一旦我們正在處理的項目完成，就會退出。 2）使用XML文件與其他供應商交換數據。 3）原型和測試，

我有類型數據集時出現問題： 1）需要複雜的查詢來過濾和保存數據。 （至少對我而言） 2）不知道Visual Studio設計師爲我寫的東西是否足夠，以便可以擴展爲類型化數據集創建的派生類。

我從來沒有遇到類型化數據集的速度問題，用戶似乎對使用它們構建的應用程序感到滿意。說實話，我沒有對可以替代類型化數據集的不同方法進行基準測試。最後，我通過使用類型化數據集的設計時間類型檢查不止一次地保存了像我這樣的新手程序員。

問候，

調試

Answer 7

我仍然可以使用他們比我更希望我所做的......他們肯定比非類型化數據集更好，但你必須要小心空值類型的字段。如果您有一個可以包含空值的Int字段，那麼您無法在字段爲null時嘗試訪問該字段，否則會引發異常。你必須首先調用IsMyIntFieldNull（）來檢查它是否爲/不是空的。這意味着你的代碼引用了這些字段之一，你需要首先檢查這個字段......這很容易加上大量額外的碼。如果輸入的數據集支持這些列的可爲空值的字段會更好，但不幸的是他們不支持。