使OR或M鬆散耦合並從其他層抽象

在n層體系結構中，放置對象 - 關係映射（OR/M）代碼的最佳位置在數據訪問層中。例如，數據庫查詢和更新可以委託給像NHibernate這樣的工具。但是，我想保留在數據訪問層內的所有對NHibernate的引用，以及遠離其下方或下方圖層的抽象依賴關係。這樣，我就可以交換或插入另一個OR/M工具（例如實體框架）或某種方法（例如簡單的香草存儲過程調用，模擬對象），而不會導致編譯時錯誤或整個應用程序的重大改進。可測試性是額外的好處。使OR或M鬆散耦合並從其他層抽象

有人可能會建議一個包裝（即接口或基類）或方法，將保持OR/M鬆散耦合，幷包含在1層？或者將我的資源指向有用的資源？

謝謝。

來源

2010-03-26 Genuine

這聽起來像你正在尋找repository模式。如果您需要更多解耦，則可以使用容器注入數據依賴關係。

來源

2010-03-26 21:28:07

我還需要數據映射器或DAOS，因爲存儲庫將位於域模型和數據訪問層之間。在此處查看更多詳細信息：http://martinfowler.com/eaaCatalog/repository.html 域模型將包含存儲庫，但無法保存對數據訪問層的引用。因此，DAO需要注入存儲庫。我的主要目標是爲每個數據訪問技術（例如NHibernate，實體框架，XML數據存儲...）創建基本的DAO類，並繼承一個通用接口。這樣，我可以隨意交換或混合它們，而無需重新編譯或重大返工。 – Genuine 2010-03-29 16:10:52

聽起來像你在正確的軌道上。 – 2010-03-29 16:19:28

服務門面模式是一個名稱。業務邏輯和數據層之間的簡單合同。

服務類或bean（稱之爲你想要的）定義和實現契約，並編排較低的數據層，通常處理跨數據對象的事務邏輯。

在Spring中，您定義了一個接口，然後實現它。一個實現可能是OR/M，另一個可能是原始JDBC或ADO.NET。在某些框架中，面向方面編程允許您在不寫任何代碼的情況下注入聲明式事務邏輯。它節省了很多頭痛。

一個告誡：當處理像Hibernate這樣的OR/Ms時，有代理類的使用。這會污染事物，因爲有幾個代理類導致問題的情況。在我看來，這是一個不應該逃離服務層的實現細節。但是對於Hibernate來說，它確實如此。不確定.NET的實現。

來源

2010-03-26 21:34:57 codenheim

我認爲服務門面模式將有所幫助。我只是試圖定義合同或界面應該是什麼樣子。我想象它將具有標準的CRUD方法以及用於會話和事務管理的一些方法。除Entity Framework之外，頂級.NET OR/M工具和ADO.NET似乎可以簡化創建這樣的合同。然而，我的擔心是，儘管它的主要缺陷，我的項目可能會與它一起。我希望推動NHibernate，但爲了防止選擇Entity Framework，請自己離開。感謝關於聲明式事務邏輯的提示。 – Genuine 2010-03-29 16:33:28

使OR或M鬆散耦合並從其他層抽象

回答

相關問題