我目前正在设计我的应用程序的持久性框架......我正在讨论两种抽象解决方案。
选项1。第一个，更简单（但可能更多地耦合到数据库是一个2层的方法。在这种方法中，数据映射器从数据库中提取数据并构建业务实体。
工作流程粗略图表：
UserEntity <= UserMapper => Database
选项2。第二种，更灵活（但可能是矫枉过正）的方法是一种3层次的方法。在这种方法中，我们有一个第三个对象，它的工作就是单独与数据库对话，并将数据数组返回给Data Mapper，然后Data Mapper创建一个对象。
粗略图：
UserEntity <= UserMapper <= UserDataRetriever => Database
显然，第一个选项的好处是它更简单，因此更快创建。第二个选项的好处是更容易更改我的持久性方法，因为我只需要更改我的DataRetriever与数据库（和相关查询）的连接。
由于这个网站的规模会非常快，我想选择最灵活的选项，而不会进入反模式的土地。
哪个更好？
答案 0 :(得分：1)
嗯，选项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以具有单独且定义明确的方法来a）检索数据，和b）地图数据。通过这种方式，您可以开始精益求精，并在必要时轻松地将这些方法重构为不同的类。
答案 1 :(得分：1)
我会使用以下内容：
Entity <=> Repository pattern <=> DataSource
存储库将执行映射（或在内部使用映射层）。
存储库本身可以使用vanilla ADO.NET，OR / M映射器，Web服务或其他任何东西。