.NET:抽象掉数据源和数据上下文

Question

我正在尝试为我最常见的开发场景编写可重用的组件:

我已经制作了一个通用的表示层来呈现领域对象和要封装在领域对象中的数据对象(dc-serializable)。我也有某种域状态/上下文，我在其中引用了所有域对象实例。这个想法是领域对象有特殊的集合，当它们第一次被访问时，按需从数据源中填充这些集合。我认为这不完全是“DDD”，但它似乎有效......

无论如何，现在我陷入了数据上下文和数据源部分。我一直在思考如何存储数据以及如何与数据源交互； zip 文件、sql-server、sql-lite-files、 Entity Framework 、nhibernate、linqtosql、mongodb 等中的 xml，我无法决定使用什么。看来我需要抽象掉数据源和数据上下文，而是决定在每个应用程序中使用什么。重要的是我没有嵌入任何对特定框架的硬依赖。

将数据上下文和数据源抽象出来并且仍然可以很好地与现有的各种框架一起轻松工作是否现实？我在想这个错误吗？这是死胡同吗？

我想要和需要的(我认为)是我的域状态，以便能够查询符合特定条件的对象的数据上下文。我不确定它是否应该能够使用整个对象图或仅单个数据对象，或者甚至不能使用具体类型而只能使用一些通用对象，或者是否应该为每个请求克隆它们。当我开始思考这个问题时，我感到很困惑......

啊啊啊

更新:

我将 DataContext/DatabaseContext(例如 EntityFramework)视为一个模块/层，用于将对象缓存在内存中、执行查询、从/向任何数据源获取和存储数据以及将类型化对象返回给消费者。这样对吗？

存储库模式 (DDD) 和我的 DataContext 有什么区别？

更新 2:

基本上，这是我的模型(好还是坏？):

DataSource->DataContext/DataObject->DomainState/DomainObject->Presenter

Answer 1

It appears I need to abstract away both the datasource and the datacontext and instead decide what to use in each application. The important thing is that I don't embed any hard dependencies on specific frameworks

这就是 Repository 模式。

Whats the difference of the Repository-pattern (DDD) and my DataContext?

存储库是一种抽象与存储访问相关的所有内容的方法。它旨在满足应用程序的需求，并接收/发送回应用程序其余部分已知的对象。 DataContext 是 EF 的一个实现细节，它本身是存储库的一个实现细节。

存储库有双重用途

1. 允许您通过仅公开一个接口(interface)来更改存储数据的方式(更改数据库、使用 xml 文件等)。

2. 它将您从以数据库为中心的方法中解放出来，让您专注于领域。这非常重要，因为每次您开始首先使用数据库模式设计应用程序时，您不可避免地会尝试将应用程序的其余部分放入其中，并且您将拥有一个模仿数据库模式的贫血域。

DataSource->DataContext/DataObject->DomainState/DomainObject->Presenter

在任何应用程序中，您基本上都有查询(读取)和更新(写入)。在 99% 的情况下，Domain 仅适用于写入，因为读取没有业务规则(没有行为)，您只需选择要显示的相关数据即可。

所以对于写入，我建议采用这种流程

ViewModel (input)->Domain Processing (Entities, Services etc)-> Domain Repository

您可以通过多种方式从 View 模型获取域实体，具体取决于应用程序。如果域非常简单，您几乎不需要域， View 模型就是域，在许多情况下与数据库模式相同。

阅读

Query Repository -> ViewModel (Presenter)

当然， Controller 通常会调用查询存储库，它可能会根据从存储库接收到的数据组装所需的 View 模型(在简单的情况下，存储库会准确返回 View 模型)。