在OOP中，持久性如何與對象關係配合？

Question

因此在OOP中，對象將消息發送到其他對象。這是一個非常簡單的概念，只要所有對象都存在內存中，就很容易實現，例如，通過調用方法。

但是在現實生活中，我們將對象持久化到數據庫或其他地方，因爲沒有足夠的內存來保存所有對象。你如何在當前持久化的對象上調用方法？

好的，所以也許不可行一個對象可以封裝到它的Factory中。但是如果我想發送消息給很多對象，例如在一個循環？一個接一個地解決它們是一個經典的N + 1問題。

好的，我可以有一個倉庫，將所有必要的對象放在一個鏡頭中。但是，爲了讓我的對象得到一個Repository，是不是打破了封裝？

模式像Observer怎麼樣？是否有可能讓一個對象訂閱任何東西，知道它將被持續？

在任何語言中是否有透明的實現？

Answer 1

我不這麼認爲。 RAM對於OOP很關鍵。一旦你在RAM之外堅持了某些東西，它就不再是OOP了。

的對象實際上是將總這是在接觸物體，再加上所有對象他們「與重新接觸，再加上....要工作，一個對象需要與許多其他物體幾乎即時通訊。沒有這些，表現就會停止。 （想想虛擬內存：如果您曾經在0.5GB的機器上使用過1.5GB，您就會知道這個問題。）

基於慢速內存的存儲趨向於使用關係存儲或大塊順序數據，每個塊按鍵訪問ramdomly。我編寫了大量數據，高度交互（如此龐大的面向對象）系統，將他們的數據保存在SQL數據庫中。我必須組織數據庫，以便它可以分成管理塊，每個塊都可以獨立運行，其中幾個塊將被加載到會話中。然後，我不得不編寫大量的代碼來將表，行和列轉化爲有用的對象。要寫入數據庫，我必須扭轉整個過程。

所以要啓動程序，DB數據進入一個攪拌機，出來一個完全不同的東西。當用戶完成並保存到數據庫中時，數據會被混合並放回。內存中的對象與數據庫表沒有明顯的關係（儘管顯然可以從其他工作中創建足夠的工作）。而且，我已經能夠獲得可用的持久性。原子單位比對象或行大得多，每次轉換需要一段時間（整秒）。

我已經與ORM一起工作了（非常）。這裏的技巧是使用OO來模仿關係存儲。如果你從一個好的面向對象設計開始，但是看起來就像一個關係數據庫，那麼最終不會得到你會得到的對象。在很多情況下，這正是你想要的，並且它工作得很好。但它不是真實 OOP，可能不是你要找的。

所以我沒有找到一般的答案。快速記憶和麪向對象 - 以及慢速記憶和關係/非實際 - 是兩回事，彌補這一差距需要仔細研究具體案例和一些天才。