我正在尝试为最常见的开发方案编写可重用的组件：
我已经创建了一个通用表示层来呈现要封装在域对象中的域对象和数据对象（可串行化）。我还有一些域名/上下文，我保留所有引用的domainobject-instances。我们的想法是，域对象具有特殊的集合，这些集合在首次按需访问数据源时会从数据源中填充。我认为这不是“DDD”，但似乎有效......
无论如何，现在我被困在datacontext和datasource-part上。我一直在思考如何存储数据和与数据源交互; zip文件中的xml，sql-server，sql-lite-files，实体框架，nhibernate，linqtosql，mongodb等我无法决定使用什么。看来我需要抽象出数据源和datacontext，而是决定在每个应用程序中使用什么。重要的是我没有在特定框架上嵌入任何硬依赖。
抽象出datacontext和datasource是否现实，并且仍然可以使用各种现有框架轻松工作？我在想这个错吗？这是死路一条吗？
我想要并且需要（我认为）是我的域名，能够在datacontext中查询匹配某些标准的对象。我不确定它是否应该能够处理整个对象图或仅使用单个数据对象，或者甚至不能使用具体类型，只能处理一些通用对象，或者是否应该为每个请求克隆它们。当我开始考虑这个时，我感到非常困惑......
Gahhh
更新
我将DataContext / DatabaseContext（例如EntityFramework）视为一个模块/层，用于保持对象缓存在内存中，执行查询，从/向任何数据源获取和存储数据，并将类型对象返回给使用者。这是对的吗？
存储库模式（DDD）和我的DataContext的区别是什么？
更新2：
基本上，这是我的模型（好还是坏？）：
DataSource-＆GT;的DataContext / DataObject-＆GT; DomainState / DomainObject-＆GT;演示
答案 0 :(得分：2)
也许您可以发布一些代码示例？有点难以理解你想要做什么，但我会尝试回答你的一些问题，评论。
“我们的想法是，域对象具有特殊的集合，这些集合在首次访问它们时会从数据源中填充。这不是”DDD“，我认为它似乎有用......”
这与延迟加载有何不同？为什么需要特殊类型的收藏？这与DDD有什么关系？
抽象出datacontext和datasource是否现实，并且仍然可以使用各种现有框架轻松工作？我在想这个错吗？这是死路一条吗？
不，不是（这是死路一条）。您可以轻松创建一个没有引用持久性技术的域模型，但您仍然必须思考关于所选orm映射器的约束，例如EF不支持枚举，nhibernate可以。此外，你从一般化中获得了什么？一旦你选择了mapper，你永远不会切换映射器，即使你这样做了，如果你的解决方案的其余部分是好的，你应该在切换它时遇到一些问题（不要分散你的ISession / DbContext /周围等等）。
“存储库模式（DDD）和我的DataContext的区别是什么？”
如果您的意思是EF DbContext，当您说“我的DataContext”时，不同之处在于DbContext是特定持久性技术的表示，而存储库是一种技术无关的持久性抽象。它代表了保存实体的东西，但它不应该暴露用于实现它的技术（xml，数据库，文件存储，内存中，等等）。
总的来说，我不会这样做。概括是困难的，几乎总是时间的浪费。开发人员喜欢概括和“代码重用”的概念，但他们很少会将代码混淆和复杂性引入到解决方案中。一旦你开始重复自己，就可以创造出有效和概括的东西。不要试图预先创建这个，因为你几乎肯定会得到一些无用（或接近）的东西。此外，我看不到你带来的东西;今天的orm mappers是非侵入式的，易于使用。你还提到了一个通用的表示层，没有什么比演示文稿更具体，所以我也没有看到它的好处（但是如果你发布一些代码或者解释一下，可能会更多）。