您是否會將NHibernate用於具有遺留數據庫的項目，這部分不受您的控制？

Question

對我來說，目前的答案是：不，我會使用iBatis，因爲當數據庫模型和對象模型不同步時，NHibernate是一種痛苦。如果我沒有完全控制數據庫，那麼我會做很多工作。

爲什麼要問？

嗯，首先：我從來沒有使用過NHibernate。我只是從表面知道它。我已閱讀了關於iBatis對遺留數據庫的優勢。

第二：最近我和一個和Hibernate一起工作過的人討論過（jep，在Hibernate之前沒有'N'）。他告訴我，ORM框架現在非常先進，並提倡Hibernate。由於我對NHibernate不感興趣，因此我沒有跟蹤最近的發展。

也許我該重新考慮我的答案了嗎？

Answer 1

iBatis確實很容易將對象映射到遺留數據庫系統。

最近NHibernate 1.2和2.0有一個功能集，可能會讓你重新思考iBatis。

NHibernate使用複合鍵，它可以在較舊的數據庫中頻繁發生，它們並不總是令人愉快的工作，但支持是這樣的。

NHibernate可以利用存儲過程對實體和數據庫視圖進行CRUD操作。

集合可以是自定義存儲過程或SQL查詢。當外鍵關係不直接映射到另一側的主鍵時，集合可以使用property-ref屬性。

其中一些功能可能會剝奪nhibernate的性能/功能，即使用property-ref的Lazy Loading不起作用（完全不？），但大多數情況下都有這樣的原因。

其他幾點：（這是不是真的與你的遺留數據庫，但仍然可以幫助決定技術選擇）

NHibernate的社區顯得比iBatis的要豐富得多。我在兩個列表中，與iBatis組相比，NHibernate的支持量相當大。所以支持應該更容易。

也有越來越多的NHibernate的contrib /第三方工具。諸如NHibernate Profiler，Nhibernate查詢分析器，NHibernate Contrib，Fluent NHibernate等等。

也許你可以擴展你相信iBatis目前擁有的優勢。 NHibernate最近確實很活躍，並且獲得了許多新功能，其中很多功能可以幫助傳統/難以修改模式。

並回答這個問題，是的，我們使用NHibernate與遺留數據庫，有可怕的關係，複合鍵，斷開關係。我們還有少量基於iBatis的代碼。我們不再編寫任何更多的iBatis代碼。

Answer 2

我一直在現有的應用程序中使用nHibernate。我將它用於所有新的開發，我無意將現有的東西移植到那裏，只是沒有一個令人信服的理由，但是對於項目中的新東西來說，它工作的很好。

如果您要移植代碼，那麼您應該能夠更改數據庫以更好地與您的域模型匹配，而沒有太大影響（取決於數據庫的泄漏程度，即誰訪問它）。但是，更改域模型會影響應用程序。

Answer 3

是的，考慮NHibernate。這是有原因的黃金標準。我聽說iBATIS支持瘋狂的映射可能性，但對於NHibernate的IUserType，你可以映射任何東西，甚至是非常奇怪的列。

@Ahmad，ORM的整個目標是防止你的對象和你的模式之間的緊密耦合。如果你有這個問題，你做錯了。

此外，與NHibernate有很多自定義查詢，公式屬性和存儲過程的選項。 HQL功能非常強大，Criteria十分靈活。

我認爲如果你至少沒有加入NHibernate，你會爲你的客戶造成不良影響。