什么是数据层的正确抽象数量？

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）的地图数据。这样你就可以开始精益，并且有一个简单的方法可以在必要时将这些方法重构为单独的课程。