數據訪問層或具有CRUD方法的對象？

Question

我曾經有一個數據訪問層，它通過參數獲取對象，並使用抽象處理所需的持久性類型。在我的新工作中，架構師正在考慮在所有模型對象中實施CRUD操作（load..save..delete..update）。這些方法將通過參數來處理對象的保存。例子：load（IPersistence持久化）。我對可擴展性有一些懷疑，並且每個模型對象都必須實現所有的加載，保存，刪除和更新方法。

什麼是最好的方法？

Answer 1

我想這是永恆的問題，兩種方法都有他們的優點和缺點，並有很多追隨者誰發誓。

repository您似乎更喜歡的方法（擁有存儲庫/網關，無論您稱之爲什麼）來處理CRUD操作，使您的實際業務類更小，更精簡，因爲它們可能只包含數據和可能的驗證/業務規則。

在這種情況下，您只需執行一次CRUD操作 - 但最有可能只執行一次您正在處理的每種類型的對象。

在另一方面，smart business object做法可能認爲在給定的實體CRUD操作特定於實體無論如何，所以代碼選擇，更新，刪除這樣的實體總是將是具體的，所以它可能以及駐留在該對象本身內部。

在這種情況下，您將爲每個對象類實施一次CRUD操作 - 實際上，在這種情況下，我並未發現存儲庫方法存在任何大的缺點。

我個人傾向於自己今天的存儲庫方法，但我也看到了「智能業務對象」方法中的好處 - 兩者都是有效的，我想你只需要說服你的新架構師的立場，或者以不同的方式達成一致。

馬克

Answer 2

我認爲，在這兩種情況下，實施不應該重複，但只有一次實現和繼承（例如）根據需要。
只有非標準作業需要子類及其方法（例如自定義查詢和自定義參數）。

---

現在的問題總計爲POJO哲學辯論。讓我試着句話在我自己的話;-)：

1. 考慮到模型是具體到每一個具體的問題，因此每個應用程序
2. 考慮到很多方面都需要模型 ：持久性是模型所需的一個方面，以及驗證，文檔，用戶界面組件和消息，用戶建議，版本之間的遷移......
3. 考慮獨模型是夠硬理解，維護等等孤單的，沒有各方面的合併
4. 你推斷，任何方面應該從外在的模型對象。

我們其實只是外部化的事情是複雜的（通常情況下，需要一些編碼），並保持對POJO的事情，是很簡單的（通常聲明，經常使用註釋）。

---

沒有技術超類模型的另一個巨大優勢是，該模型可以作爲自己的「數據傳輸對象」來進行系統間的信息：

1. 層之間
2. JVM之間（通過序列化），例如在機器之間

如果我們的模型類具有技術超類，它們在這樣的各種環境中將不會有用。例如：一個模型對象上

1. 持久性只在某些層（在建築選擇）是經常可用。例如，只有業務層纔有權訪問數據層來堅持。
2. 在從一臺機器到另一臺機器的數據遷移過程中，每臺機器都可以在自己的數據庫上工作。因此，如果模型對象不攜帶指向數據庫的指針，則可以自由傳輸模型對象;每個服務員都應該使用自己的數據庫。 對於相同的模型對象，其他方面可能會有變化，如果這些方面不是由同一個對象攜帶的話，這是便利的。

Answer 3

DAL一路。

您希望能夠隔離您的事務，以便對象不應該意識到它們的持久性。否則，代碼可能會導致無法維護的噩夢，對象可能會激活數據庫往返行程，並且很難將大量事務處理爲一個原子操作。

我發現這很難。 :)