我正在使用SQL Server數據庫大約20到30個表的.NET Web應用程序。大多數表格將作爲類包含在.NET解決方案中。 我寫了自己的數據訪問層來讀取對象，並將它們寫入數據庫。 整件事只包含幾個類，很少的代碼行使用泛型和反射來找出要使用的SQL和參數。 現在，這樣的事情可以通過使用NHibernate（或相似框架）和一些同事聲稱愚蠢的我不使用它。 我沒有使用它的主要理由是我想要對我的應用程序進行最大限度的控制，確切地知道所有事情都做了什麼以及如何工作，即使這會花費我更多的開發時間。 我也不喜歡這個事實，我必須將我的數據庫映射到XML文件（我自己的解決方案可以讓我將它映射到實體類文件中）。對我來說，不要爲我的項目使用NHibernate是愚蠢的嗎？
所以，我想從你那裏聽到的是，在這種情況下不使用NHibernate真的很愚蠢嗎？ 我真的很無知，或者使用我自己的解決方案是不是很奇怪的想法？
我認爲現在真的沒有任何理由推出自己的持久性框架，因爲有很多好的選擇。你不必使用NHibernate（雖然這是一個不錯的選擇），但我會認真考慮使用在行業中經過很好測試和建立的東西，因爲它往往會表現得更好，並且缺少你自己編寫的東西。
用Ayende Rahien的話說......不要從客戶那裏偷東西（通過浪費時間編寫自己的框架）。 – 2009-09-29 14:46:50
此外，標準很好。從現在起2年內必須維護你的代碼的可憐傢伙可能不知道你是如何執行DAL的。如果你要使用ORM，他只需要閱讀該ORM，他就會前進幾英里:) – cwap 2009-10-04 20:37:51
這可能是愚蠢的寫入，而不是使用NHibernate自己的類，但它的少愚蠢給你已經寫他們，繼續使用自己的類。也許。
人們傾向於使用已經編寫好的框架，因爲它們已經被編寫（並經過測試）。
但是有自己的價值。只有你和你的同事可以對你的域進行假設。像NHibernate這樣的通用框架不能做出很多假設，因爲這不會使它變得非常普遍。
當您推出自己的產品時，您可以將這些假設烘焙到您的框架中，以製作更加簡化的自然API。也就是說，如果你重新開始，我會建議採取一個現有的框架，幷包裝它以更好地滿足你的需求。但既然你已經有了一些東西，它對你有用，我不確定我會建議將它換成其他東西。
你有幾種可能比你重新發明輪子更好。讓我來列舉兩個最有可能的選擇：
使用實體框架爲您DAL + DAO。這將使你的課程（你已經寫好的課程）過時，因爲EF將創建自己的課程，並且你將掌握最新的語言能力和技術。
使用流利的NHibernate所以你不必使用XML映射。這樣你就可以保留你編寫的業務層對象類，避免繁瑣的NHibernation XML文件。這都是C＃。
你的想法很好。你想要控制。沒關係。但是現在使用你自己的DAL有點愚蠢，因爲你基本上是在重新發明輪子，而且你還沒有測試/ bug代碼，需要花費相當多的時間來開發+測試+調試。
如果我是你，我會選擇＃2選項，因爲我已經完成了選項＃1，並且我知道必須自定義很多事情才能使EF正常工作。 EF將準備好V2。
擊敗我。 @ Ruud的問題尖叫出來，由流利NHibernate解決。好決定。 – Rap 2009-09-29 14:56:58
Minor nitpick：EF v2 = EF v4與.NET 4.0版本號一致:) – 2009-09-29 17:12:54
我不會說你愚蠢，因爲我過去完全一樣。然後我開始使用NHibernate，並想知道爲什麼我把自己推出。這很好，給它一個。
我認爲這是一個平衡控制的問題。你說你想要控制，而你不想映射。如果這種控制的代價是增加了開發和維護成本，並且生成工作代碼需要更長的時間，那麼這是一個問題。
我個人看不出滾動框架有問題，只要它簡化了重複性任務，並且由於解釋空間較小而使開發更具生產力且代碼更穩定。我們推出了自己的框架，其中包括持久性/數據訪問實現。然而，我們做這件事的原因很具體。在這種情況下，它應該在DDD環境中工作，這與Evans所描述的要比現有產品提供的要多得多。
我認爲，不同之處在於，我們瞭解到有前期成本，並且最終會通過節省開發時間來平衡自身。當然，如果您正在編寫手動管理連接，映射數據等的代碼，那麼您可能會走錯路。至少，您可以使用Enterprise Library之類的東西來幫助您管理連接和命令構建的乏味。但是，我也認爲，如果你沒有重用 - 沒有什麼是你可以抽象並應用到其他項目的「框架」類型的實現，那麼你正在創建一個維護噩夢和時間沉淪，你將成爲唯一的擁有者的。
有許多很好的持久性工具，經過很好的測試和性能驗證（NHibernate，Linq到實體，LLBL Gen Pro）。如果你的需求與存在的正常持久性框架非常不同，那麼我會推出自己的。但是，如果可能的話，我想要利用現有工具的測試和優化。如果我想擁有構建我自己的ORM工具的經驗，並且願意忍受這些缺點（沒有經過多年測試或優化的工具），那麼我也可能推出自己的產品。 ，加快上市）。
制定你自己的解決方案，特別是當它看起來工作正常並且如你所說簡單時，既不知道也不奇怪。在很多情況下，最好這樣做比在nHibernate這樣的單獨項目上增加依賴。
也就是說，當然也有很多情況，完全相反的情況是正確的。 :)
這真的取決於你的項目和團隊。如果您正在開發一個企業應用程序，最終將得到其他人的支持，堅持行業標準可能是一個好主意，即使這意味着更多的工作。
這裏的所有答案都很棒，但我真的很驚訝沒有人提到過Castle ActiveRecord，這聽起來和你的框架非常相似，並且真正簡化了NHibernate的接口。這是使Ruby on Rails如此受歡迎的模式之一！
Ayende Rahien（的主要NH開發商之一）在Oredev介紹了ActiveRecord的一個偉大的介紹，幾年前，我強烈建議：http://www.viddler.com/explore/oredev/videos/89
我們也用我們自己的數據訪問層和實體類。我們還有一個代碼生成器，用於爲我們生成所有這些類。但現在我們正在使用實體框架，我們更高興。
簡單的建議：開始學習nHibernate或你喜歡的任何東西，並開始在你的下一個項目中使用它。
這取決於他們的意思是「愚蠢的」。
如果說「愚蠢」，他們的意思是你不應該在第一時間寫下你的持久層，他們可能是對的，但那是因爲溢出的牛奶而哭泣。
如果用「愚蠢」的意思，你應該重寫所有你現有的代碼來使用另一個框架（比如NHibernate），當它已經和你一起工作時，它們可能是錯誤的（儘管有些東西可以說NHibernate與你的可能的錯誤數）。
如果用「愚蠢的」表示整個團隊都知道NHibernate很冷，並且已經在其他代碼中使用了，所以通過使用你的框架，你在團隊中變得更加困難，他們是完全正確的，你應該儘可能快地重構NHibernate中的代碼，然後再有更多的代碼被鎖定到你的框架中。
如果說「愚蠢」，他們的意思是沒有人知道NHibernate，他們只是喜歡它，然後......沒有人贏。他們很挑剔，你實現了一個你不需要的框架......讓我們把它稱爲一個領帶。
所有這些說，每個人都應該寫一個或三個持久性框架。這些可能不應該在任何船舶上結束，但這是一個很好的練習。你犯的唯一錯誤就是團隊必須維護你的良好運動。
實體空間 - http://www.entityspaces.net/Portal/Default.aspx
也是一個很好的工具。
我結束了使用流利NHibernate的工作。 我的所有實體類都是使用ActiveRecordGenerator生成的（http://code.google.com/p/active-record-gen/）
NHibernate是一個選項，作爲ADO.NET實體框架（也檢查它）。 – 2009-09-29 13:20:49
搜索NHibernate.Mapping.Attributes - 無需在XML中存儲數據庫元數據。 – 2009-09-29 13:30:31
在使用NHibernate的時候，你也可以知道「確切地說，一切做什麼以及如何工作」源代碼是隨時可用的。還有其他很棒的工具，如NHProf向您展示正在發生的事情。 – 2009-09-29 14:15:24