什麼是數據層的正確抽象數量？

Question

我目前正在設計我的應用程序的持久性框架......並且我正在討論抽象的兩種解決方案。

選項1.第一，和更簡單的（但可能更耦合到所述數據庫是2分層的方法。在這種方法中，數據映射器拉來自數據庫的數據，並建立業務實體。

粗糙圖工作流程：

UserEntity <= UserMapper => Database 

選項2第二個，更靈活（但可能矯枉過正）的方法是一個3層的方法在這種方法中，我們有第三個對象是誰的工作是單獨說話。數據庫，並返回一個將數據遺留給Data Mapper，然後Data Mapper創建一個對象。

粗糙圖：

UserEntity <= UserMapper <= UserDataRetriever => Database 

顯然，第一種方案的好處是，它更簡單，因此更快地創建。第二個選項的好處是更換我的持久性方法更容易，因爲我只需要將DataRetriever的連接更改爲DB（以及相關的查詢）。

由於本網站的規模將快速增長，因此我想選擇最靈活的選項，而不必進入反模式的土地。

哪個更好？

Answer 1

我將使用以下：

Entity <=> Repository pattern <=> DataSource 

存儲庫會做的映射（或在內部使用的映射層）。

存儲庫本身可以使用vanilla ADO.NET和OR/M映射器，web服務或其他任何東西。

Answer 2

那麼，對於選項2圖將是多一點涉及：

UserEntity <= UserMapper <= UserDataEntity <= UserDataRetriever => Database 

UserMapper將必須映射從一種類型到另一種，因此UserDataEntity。從UserDataRetriever直接映射到UserEntity在概念上很尷尬。你可能會暗示下圖的第二個選項：

UserEntity <= UserMapper <= [list of arrays] <= UserDataRetriever => Database 

反正選項1是一種方式，UserMapper本身具備的功能不同，這裏：[list of arrays]/UserDataEntity <= UserDataRetriever。

這兩種選擇本身都不會更好。它取決於實體的數量以及在持久層和域層之間映射的容易程度。

你可能想嘗試選項1.5，而不是：你的基本方法是選擇1。同時你設計UserMapper有獨立和明確的方法來一）檢索數據，和b）的地圖數據。這樣你就可以開始精益，並且有一個簡單的方法可以在必要時將這些方法重構爲單獨的課程。