entity-framework-4 - Entity Framework 4 : Does it make sense to create a single diagram for all entities?

Question

我写了一些关于 Entity Framework 的假设，然后是几个问题(所以请纠正我错误的地方)。我正在尝试将 POCO 与 EF 4 一起使用。

我的假设:

• EF 图表只能存在一个数据上下文。
• 数据上下文可以引用多个实体。
• 如果您有两个数据源，例如 MS SQL Server 和 Oracle，则 EF 需要两个不同的图表来访问数据。
• EF 图数据上下文是“工作单元”，对于图中的任何内容都有一个 Save()。 (当然，您可以将其包装在 UnitOfWork 类中，但它本质上具有相同的职责)。

假设这是正确的，这是我的问题:

• 如果您不将所有实体保留在同一个 EF 图上，如何维护数据完整性，例如没有“客户”就无法存在“订单”？存储库加载数据的功能只是为了验证完整性，还是我们“尝试/捕获”数据库引用完整性错误？

• 您不会为每个实体创建一个 EF 图吗？例如，我不希望对客户的更改和对产品的更改一起写入，因为它们没有任何内容彼此相关(将它们放在同一个图表上会导致它们被写在一起)。或者 EF 图的范围是否涵盖存储在同一存储介质中的所有类似实体？

像这样划分实体是常态吗，还是只有一个图表包含所有实体？我会认为是后者，但这种想法逐渐战胜了我。

Answer 1

拥有一个包含所有实体的大型 EDM 通常不是一种好的做法，也不建议这样做。
使用一台大型 EDM 会导致一些问题，例如:

元数据加载时间的性能问题:
随着模式文件大小的增加，解析和创建该元数据的内存模型所需的时间也会增加。

View 生成中的性能问题:
View 生成是将用户提供的声明性映射编译为客户端实体 Sql View 的过程，该 View 将用于查询实体并将其存储到数据库中。该进程在第一次查询或 SaveChanges 发生时运行。 View 生成步骤的性能不仅取决于模型的大小，还取决于模型的互连程度。如果两个实体通过继承链或关联连接，则称它们是连接的。同样，如果两个表通过外键连接，则它们是连接的。随着模式中连接的实体和表的数量增加， View 生成成本也会增加。

杂乱的设计界面:
当您从大型数据库模式生成 Edm 模型时，设计器界面上充斥着大量实体，很难理解实体模型的整体外观。如果您对实体模型没有很好的了解，您将如何自定义它？

智能感知体验不太好:
当您从包含 1000 个表的数据库生成 Edm 模型时，您最终将得到 1000 个不同的实体集。想象一下，当您输入“上下文”时，您的智能感知体验会如何。在 VS 代码窗口中。

杂乱的 CLR 命名空间:
由于模型架构将具有单个 EDM 命名空间，因此生成的代码会将类放置在单个命名空间中。

有关更详细的讨论，请查看 Working With Large Models In Entity Framework – Part 1

解决方案:
虽然没有现成的解决方案，但它建议您应该模型中自然断开的子集这意味着根据您的域模型，您应该建立不同的域模型集，每个域模型都包含相关的对象，而每个集都是不相关的并且与另一个集断开连接。中间没有外键可能是分离的好兆头。这是有道理的，因为在大型模型中，您的应用程序通常不需要将数据库中的所有表映射到一个实体模型才能工作。

即使这种分离不是 100% 可能的(这意味着某些表的子集具有指向数据库中其他表的外键)，它仍然鼓励您将它们分开。当您这样做时，您必须承担适当设置外键的责任。没有导航属性允许您获取表示该外键的实体。当然，如果需要，您可以在其他容器中手动查询该实体。

另外，有关如何在重用类型时将一个大型实体模型拆分为较小实体模型的一些提示和技巧，请查看: Working With Large Models In Entity Framework – Part 2

关于您的问题:订单和客户属于同一个自然域，应该保存在同一个EDM中。就像我说的，您可以将它们分散在 2 个不同的实体数据模型中，但随后您必须负责设置适当的外键，否则您将得到运行时异常，同样，客户 和产品应保存在单独的实体数据模型中。遵循这些规则，您可以在数据访问层中提出明确定义的域集设计。