ORM架构：一个或多个模型（实体框架）

Question

情境：

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

问题：

每个子装配体是否更好地包含自己的小型模型，或者它们是否都共享相同的大型模型？

讨论：

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

修改

1. Ray Vernagus对于在模型周围设置明确定义的边界有一些好处（我认为）。我真的喜欢这个想法。我已经通过在我的子装配中使用单独的模型来实现这一点，因为我的子装配具有明确定义的范围。这够了吗？

2. 考虑所有域模型都在同一个DAL程序集中的情况，并且许多实体基于相同的表并具有相同的名称。除了需要在saparate名称空间中，这是一个坏主意吗？

Answer 1

Eric Evans在他的书Domain Driven Design中恰当地描述了这种情况。他的建议是在模型周围设置边界，并明确定义它们适用的范围。这称为Bounded Context和Context Map。

听起来您需要明确是否要拥有一个通用的域模型，或者每个DAL程序集是否应该绑定到自己的模型。如果您需要一个中央域模型，您可能需要考虑在主程序集中定义这样，然后让DAL程序集通过该模型与之通信。否则，您可以保持每个DAL程序集的单独模型，但定义明确的有界上下文。

希望有所帮助！

Answer 2

我使用过这两种类型，我相信子模型要好得多。特别是完整的模型将是大的并且不同的子集相对独立。或者在本地使用在概念上不同的解决方案部分。您可以获得一系列更清晰的解决方案（更加复杂地进行扩展），并且您很少会发生影响几个概念上不同的系统区域的更改。

最大的问题是如果你有几个系统的部分延伸到几个概念区域，因为在模型之间跳转并不是微不足道的（但是可以桥接）......

BR

丹尼尔

Answer 3

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