场景:
我正在研究一个包含许多程序集的解决方案。主程序集引用具有大型 EF 模型的 DAL 程序集。我正在处理一个包含自己的较小 EF 模型的 DLL。两种模型都将连接到同一个数据库。我正在处理的 DLL 会将数据返回到主程序集，但它不一定必须从其模型返回实体。
问题:
是每个子组件包含自己的小模型更好还是它们都应该共享同一个大模型？
讨论:
- 一方面，如果我共享主装配体的模型，则子装配体可以将实体返回到主装配体。
- 另一方面，共享一个大型模型会将每个组件耦合到该模型。这似乎会增加对该模型的更改可能会破坏子组件的机会。我可能无法安全地对主模型进行有用的更改，因为担心会破坏其中一个子组件。
编辑:
Ray Vernagus 关于为您的模型设置明确定义的边界有一些优点(我认为)。我真的喜欢这个主意。我已经通过在我的子组件中有一个单独的模型来做到这一点，因为我的子组件有一个明确定义的范围。这够了吗？
考虑这样一种情况，其中所有域模型都在同一个 DAL 程序集中，并且许多实体都基于相同的表并具有相同的名称。除了需要在单独的命名空间中，这不是个好主意吗？
最佳答案
Eric Evans 在他的书 Domain Driven Design 中恰本地描述了这种情况。 .他的建议是围绕您的模型设置边界并明确定义它们的应用范围。这被称为 Bounded Context和 Context Map .
听起来您需要明确说明是否要拥有一个公共(public)领域模型，或者每个 DAL 程序集是否应该绑定(bind)到它自己的模型。如果您想要一个中央领域模型，您可能需要考虑在您的主程序集中定义这样的模型，然后让您的 DAL 程序集通过该模型与其通信。否则，您可以为每个 DAL 程序集保留单独的模型，但定义明确的限界上下文。
希望对您有所帮助!
关于.net - ORM 架构 : One or Multiple Models (Entity Framework)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5260200/