NHibernate真的「透明」，如維基百科所述？

NHibernate的用於普通老式CLR對象（波蘇斯）提供透明的持久性。

在我的世界中，這意味着我不必在我的類中更改我的代碼，所以我不必爲屬性添加屬性，也不必繼承超類或實現接口。

在我的世界裏，這也意味着「引擎」，在這種情況下NHibernate，負責讀取類並將它們無縫地保存在數據庫中。

但是，當我閱讀NHibernates網頁時，我認爲它根本不透明。所以，我的問題是真的，如果這些說法是正確的，或者如果我錯過了什麼：

選項1：您的解決方案（link）
選項來創建一個討厭的.hbm.xml文件每個類 2：使用功能NHibernate，你有你的解決方案創建一個爲每個類單獨的地圖類，並保持在PersistenceModel類（link）

是我的類的列表這是真的？

因爲如果是這樣，這是非常非常「透明」。正如我看到的，試圖在現有項目中切換到NHibernate是因爲它涉及編寫數百個XML文件，然後在類更改時更新這些XML文件，或者創建數百個映射類並將其更新爲真正的課程改變了。

我是否正確？

來源

2013-10-23 Ted

對於選項1）您可以（也可能應該出於優化原因）在單個.hbm.xml文件中包含所有映射。如果你有很多類，所有文件的加載時間可能會相當大。 – dwerner

我希望能夠聽到降薪的理由......這是一個完全合法的問題。 – Ted

也許是因爲這個問題幾乎是一個社論，這是一個問題與答案網站，不鼓勵以意見爲基礎的帖子。原來，標題中出現拼寫錯誤，這也可能導致人們認爲它不像他們所期望的那樣精心構造。 – dwerner

不，你沒有得到它的權利。

NHibernate和其他幾個ORM，旨在簡化您的開發過程。

它具有嚴重的好處，它爲您提供了一層抽象，可測試性，可重用性。

我不明白爲什麼你抱怨的配置..

有代碼首先從EF。最小的配置，它不能得到比這更好的。

我曾經爲一家公司工作過，那裏有成千上萬的開發人員，並不是所有的人都知道oracle的內部和外部。但像抽象這樣的冬眠，他們可以輕鬆完成他們的工作。

來源

2013-10-23 18:04:21 DarthVader

「投訴」是因爲它聲稱（至少在維基上）是透明的，而不是。在一個包含數百個類的項目中，維護一個單獨的XML文檔（或數百個文檔）不是一個好處。最小配置是沿着「Eloquera原則」的東西，也就是說，對象沒有變化，沒有額外的文件來跟蹤映射。類似這樣的東西確實是透明的（如果有效的話）。 – Ted

是的，首先從實體框架看代碼。 – DarthVader

我猜你的意思是實體框架是平等的......呃...累贅？因爲它看起來有相同的問題（從我剛剛看到的那個快速查看）... – Ted

至於「透明」去，這是有些主觀，但預計將在

using(ISession s = sessionFactory.OpenSession()){ 
    using(ITransaction t = s.BeginTransaction()){ 
     // do some work 
     t.Commit(); 
    } 
}

領域內做的操作。如果你想獲得任何形式的會議緩存發生的事情。此外，操作不應該跨越交易。至於不得不「創建數百個XML文件」 - 有一些工具可以從現有模式生成映射。

https://www.google.com/#q=nhibernate+mapping+generator

來源

2013-10-23 18:05:31 dwerner

提到的並不是指簡單的配置的透明度，但最小的無以更改爲域模型。當然，它在你的領域模型中引入了一些要求，但我認爲這些要求很好。

必須存在無參數的構造函數。它可能受到保護，因此對正常代碼隱藏起來。
所有方法和屬性必須聲明爲虛擬。（這也許是僅適用於不同的代理解決方案和延遲加載的要求。）

我認爲這兩點作爲一個適當的解決方案，因爲它是合法的派生類可能要重寫我的任何東西來改變行爲或介紹檢查。無論如何，他們應該能夠做到這一點。

對於您打算使用的每種實體類型（它們可以存儲在一個大的xml文件中），您將需要一個hbm-xml-configuration-element。流利的NHibernate並不神奇，但會生成NHibernate使用的內存配置條目。如果你想避免班級地圖，你可以使用Fluent NHibernate conventions。

來源

2013-10-23 18:17:39 sisve

無參數構造函數根本就不是問題。但是，所有的方法和屬性都必須聲明爲虛擬的？我還沒有看到任何，但如果真的，那不是在+方面... :-( – Ted

似乎有東西虛擬只是延遲加載的要求。http：// thatextramile。be/blog/2009/03/must-everything-be-virtual-with-nhibernate/ – sisve

IMO延遲加載是最重要的用例的一部分。 – dwerner

我認爲透明度比您制定的要求還要多。我認爲NHibernate與任何ORM都可能是透明的。我認爲ORM不可能是真正透明的。

當我讀了它，你的「透明」的定義是：

不要在你的類來改變代碼，具體...
- 沒有添加屬性的屬性
- 不必從超類
- 繼承沒有實現接口
ORM需要照顧......
- 從數據庫讀取的類「無縫」
- 持久化類數據庫中的「無縫」

根據這一定義，NHibernate的通過與飛行顏色。映射存儲在您的域類外部，以便您的域類完全可以忽略這樣一個屬性存儲在哪個特定列中的事實。你可以選擇來存儲你的班級內的屬性，但你不必。

您不必爲您的域類使用任何特定的基類或接口。正如Simon Svensson提到的那樣，NHibernate不需要基類，而需要將類的所有成員聲明爲virtual。這是需要的，以便NHibernate可以將惰性加載行爲注入到您的類中。

至於ORM無縫閱讀和保持對象，我認爲這是相當無縫，約無縫銜接，我會想：

var customer = session.Get<Customer>(42); 
customer.Email = "[email protected]"; 
customer.Addresses.Remove("Home"); 
session.SaveOrUpdate(customer);

比任何更完美，我們開始冒險進入令人毛骨悚然的閱讀代碼的土地。

但是，我不認爲上述「透明」的定義是完整的。我期待一個提供「透明持久性」的ORM，它允許我像在.NET中那樣編寫我的領域類，充分利用不同類型的集合，如詞典和集合，利用繼承和多態性，枚舉等。我希望能夠操縱多對多的關係，而不必因爲更緊密地模擬關係數據庫的工作方式而被迫通過中間類。 NHibernate也通過了所有這些與飛行顏色。

但這些東西都需要映射。否則，除了將您限制爲最接近表和列的面向對象設計元素的子集之外，別無選擇。因此，映射所需的事實可能是負數，但它會導致更大的優勢。

我第二次西蒙·斯文森的建議，你再看看流利的NHibernate。假設您的數據庫模式和對象模型的結構是一致的，合理的，您可以使用FluentNH的Auto Mapping大大減少您必須執行的手動映射的數量，並根據需要僅在某些地方使用override。

至於維基百科是否公平地使用術語「透明」，這聽起來更像是討論Wikipedia Talk page，而不是StackOverflow。我認爲這是一個close enough description for an encyclopedia。即使glass isn't 100% transparent，但我們仍然call it transparent。

如果您需要比ORM提供的更多透明度，您可以嘗試查看文檔數據庫。文件與表格中的行相比，具有更大的相似性。

來源

2013-10-24 22:51:27

NHibernate真的「透明」，如維基百科所述？

回答

相關問題