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

【问题标题】：ORM Architecture: One or Multiple Models (Entity Framework)ORM 架构：一个或多个模型（实体框架）
【发布时间】：2011-03-10 13:23:35
【问题描述】：

场景：

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

问题：

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

讨论：

一方面，如果我共享主装配体的模型，子装配体可以将实体返回到主装配体。
另一方面，共享一个大型模型会将每个装配耦合到该模型。这似乎会增加对该模型的更改可能会破坏子组件的机会。我可能无法安全地对主模型进行有用的更改，因为害怕破坏其中一个子组件。

编辑：

Ray Vernagus 有一些优点（我认为）关于在模型周围设置明确定义的边界。我真的喜欢这个主意。我已经通过在我的子组件中拥有一个单独的模型来做到这一点，因为我的子组件具有明确定义的范围。这够了吗？
考虑所有域模型都在同一个 DAL 程序集中并且许多实体基于相同的表并具有相同名称的情况。除了需要在单独的命名空间中，这是一个坏主意吗？

【问题讨论】：

【解决方案1】：

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

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

希望有帮助！

【讨论】：

+1 表示第一段。在我明白你在说什么之前，我不得不把第二段读了好几遍。 ;-p
看书吧！我当然不能公正。 =)
部分问题是我不知道自己想要什么（因此提出了问题）。我的老板想要每个人都使用的单个 DAL 组件中的一个巨型模型。我倾向于将模型分解为更小的子模型，无论它们是否位于单独的组件中。在这种特殊情况下，子模型不在 DAL 程序集中，而是嵌入到业务子程序集中。
好吧，不幸的是，我的 sprint 不到一周就结束了，如果我买了这本书，我需要在收到书之前做出决定。
如果您有 15 分钟的时间，您可以观看对 Eric Evans 的采访，其中他更多地谈论了有界上下文：infoq.com/interviews/domain-driven-design-eric-evans

【解决方案2】：

这两种类型我都用过，我相信子模型要好得多。尤其是完整的模型会很大，不同的子集相对独立。或者在解决方案的概念不同部分本地使用。您会获得一组更清洁的解决方案（在复杂性方面可以更好地扩展），并且您很少有影响几个概念上不同的系统区域的更改。

最大的问题是如果系统的多个部分跨越多个概念领域，因为在模型之间跳转并非易事（但可以桥接）...

丹尼尔

【讨论】：

【解决方案3】：

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

【讨论】：