使存儲庫持久化無知的優點/缺點是什麼？

通常，知識庫應該知道我們決定使用哪個數據庫的實現細節。使存儲庫持久化無知的優點/缺點是什麼？

a）但也有什麼優點/缺點存儲庫持久性無知（即不知道什麼是持久性介質用於存儲數據）。唯一的優點我能想到的是，現在同樣倉庫實現可以不管用於該介質數據被持久

b）中假設庫由持久性無知，那麼無論是庫接口及其實施應該駐留在域組件？！

謝謝

來源

2012-10-11 user702769

那麼，使用Repository模式的重點是將持久邏輯與域邏輯分開，因此，您可以對不同的數據存儲使用相同的域實現。因此，存儲庫的實現必須在某種程度上取決於數據庫的實現，這似乎很自然。

a）我認爲主要的缺點是性能。存儲庫庫越抽象，你需要設計和實現更多的抽象層次，涵蓋更多的案例。但是，專業知識庫會更好地表現出來，知道其底層商店的全部能力。

另一個缺點是開發維護成本。我覺得這些缺點超過具有完全通用的結構......

b）對於較小的項目我的答案是任何好處「也許」，但對所有其他項目，它是一個堅實的「否」。它與持久性無知沒有任何關係。我總是試圖遵循的最佳做法是關注分離。如果他們試圖做不同的事情，然後把它們分開。它會在以後的很多噩夢中拯救你。

任何進一步的想法|的想法，我很願意聽到他們太:)

來源

2012-10-12 11:47:57

「另一個缺點是開發和維護成本。」爲什麼要讓存儲庫不知道持久性介質會增加開發和維護成本（我不認爲持久性中不可知的存儲庫會打破單一責任原則）？我期望的恰恰相反？！ – user702769

如果它在不同的程序集中，它不會破壞SRP。然而在（b）中我認爲它確實如此。域邏輯程序集的目的不同於提供持久性不可知的數據訪問的抽象層。「另一個缺點是開發和維護成本。」在這個問題上，我考慮過你是否超出了範圍，並使其過於通用（即支持大量媒體）。當然，如果你留在項目的範圍內，這將降低成本。謝謝你指出，我不得不解釋清楚:) – 2012-10-13 12:16:55

「它不會破壞SRP，如果它在不同的程序集中。」因此，即使我們使存儲庫持久性不可知，只有存儲庫接口可以駐留在域程序集內，而不是存儲庫實現，否則我們打破SRP（或者說我們打破了關注點分離的規則）？ – user702769

這聽起來有點像在想你自己。經典的存儲庫模式旨在將持久性細節從實現值對象和實體（DDD中的基本構建塊）中抽象出來。在不知道存儲庫持久性的情況下會獲得什麼，如果它的目的是隱藏持久性？

有些人覺得他們應該抽象出持久性抽象的細節，考慮到'通用ORM'而不是'NHibernate'，但在這裏我認爲這對你自己來說太聰明瞭。你有一個IRepository，這很好。如果你想要一個NHibernateRepository和EventStoreRepository，就去做吧。

來源

2012-10-12 01:52:36

我認爲涉及的代碼較少，因爲通常Repository位於Data Mappers之上，它知道正在使用的持久性介質。因此，當你有N個持久性媒介時，你必須編寫「N個Repository實現+ N個數據映射器」，而如果Repository不知道持久性媒介，我們只需要編寫「1 Repository + N Data Mappers」？還是我的推理有缺陷？ – user702769

在經典的DDD公式中，每個存儲庫都很容易編寫 - 通常只是泛型類的具體實例。然後你添加你需要的查詢，你必須做的。 –

抱歉，如果我正確理解你，讓Repository不知道持久性介質是沒有意義的，主要是因爲它只需要更多的努力/代碼（與編寫持久性介質不可知的存儲庫相比）來編寫知道存儲庫的知識庫持久性媒介？ 2 - 雖然我必須承認，但我還是不太明白，讓Repository不知道持久化介質有什麼缺點？！ – user702769

而不是製作庫「持續性無知」，你可能希望從代碼中分離出一個信息庫接口。例如，CustomerRepository可由兩個NHibernateCustomerRepository和EFCustomerRepository來實現。這樣，實現之間的切換可以像更改配置一樣簡單（至少在幻想世界中）。這有一些真實的用途：例如，某些客戶堅持使用專有解決方案。

來源

2012-10-13 03:18:42

使存儲庫持久化無知的優點/缺點是什麼？

回答

相關問題