ORM体系结构:一个或多个模型(实体框架)

Question

场景：

我正在研究一个有很多程序集的解决方案。主程序集引用具有大EF模型的DAL程序集。我正在处理一个DLL，其中包含它自己的更小的EF模型。这两种模型都将连接到同一个数据库。我正在处理的DLL将将数据返回到主程序集，但它不一定要从其模型返回实体。

问题：

是每个子组件包含自己的小模型更好，还是它们都应该共享相同的大模型？

讨论：

• 一方面，如果我共享主程序集的模型，子程序集可以将实体返回到主程序集。
• 另一方面，共享一个大型模型将每个组件耦合到该模型。这似乎会增加对该模型的更改可能会破坏子程序集的可能性。我可能无法安全地对主要模型进行有益的更改，因为我担心会破坏其中一个子程序集。

编辑：

1. 雷·维纳格斯( Ray Vernagus )在为你的模特们设置明确界定的赏金方面有一些优点(我认为)。我真的很喜欢这个主意。我已经这样做了，在我的组件中有一个单独的模型，因为我的组件有一个明确定义的范围。够了吗？
2. 考虑这样的情况:所有域模型都在同一个DAL程序集中，许多实体基于相同的表并具有相同的名称。除了需要在分离的名称空间，这是不是一个坏主意？

Answer 1

埃里克·埃文斯在他的书“领域驱动设计”中恰当地描述了这种情况。他的建议是围绕您的模型设置边界，并明确定义它们应用的范围。这被称为有界上下文和上下文地图。

听起来，您需要明确说明您是否想要一个公共域模型，或者每个DAL程序集是否应该绑定到它自己的模型。如果您想要一个中心域模型，您可能需要考虑在您的主程序集中定义这样的组件，然后让DAL程序集通过该模型与它通信。否则，您可以保留每个DAL程序集的单独模型，但可以定义显式有界上下文。

希望这能帮上忙！

Answer 2

我使用了这两种类型，我相信子模型要好得多。特别是完整的模型将是大的和不同的子集相对独立。或在解决方案的概念上不同的部分局部使用。您获得了一组更干净的解决方案(规模更复杂)，并且很少有影响几个概念上不同的系统区域的更改。

最大的问题是，如果系统的几个部分跨越了几个概念领域，因为在模型之间跳转并不简单(但可以桥接)。

BR

丹尼尔

Answer 3

出于可维护性的原因，我会使用一个大型模型。在任何情况下，当您的模型由于模式中的数据库更改而发生更改时，您必须传播这些更改，因此如果您有多个模型.