我写了一些关于实体框架的假设，然后是几个问题（所以请纠正我错误的地方）。我正在尝试将 POCO 与 EF 4 一起使用。
我的假设：
- EF 图只能存在一个数据上下文。
- 数据上下文可以引用多个实体。
- 如果您有两个数据源，例如 MS SQL Server 和 Oracle，则 EF 需要两个不同的图表来访问数据。
- EF 图数据上下文是“工作单元”，对于图中的任何内容都有一个 Save()。 （当然，您可以将其包装在 UnitOfWork 类中，但它本质上具有相同的职责）。
假设这是正确的，这是我的问题：
如果您不将所有实体保留在同一个 EF 图上，那么如何维护数据完整性，例如没有“客户”就不能存在“订单”？这仅仅是存储库加载数据以验证完整性的功能，还是我们“尝试/捕获”数据库引用完整性错误？
您不会为每个实体创建一个 EF 图吗？例如，我不希望对客户的更改和对产品的更改一起编写，因为它们彼此无关（将它们放在同一个图表上会导致它们一起编写）。或者 EF 图的范围是否涵盖存储在同一存储介质中的所有类似实体？
像这样划分实体是常态吗，还是只有一个图表包含所有实体？我会认为是后者，但这种想法已经占据了我的上风。
使用一个包含所有实体的大型 EDM 通常不是一种好的做法，也不建议这样做。
使用一台大型 EDM 会导致一些问题，例如：
元数据加载时间的性能问题：
随着模式文件大小的增加，解析和创建该元数据的内存模型所需的时间也会增加。
视图生成中的性能问题：
视图生成是将用户提供的声明性映射编译为客户端实体 Sql 视图的过程，该视图将用于查询实体并将其存储到数据库中。该进程在第一次查询或 SaveChanges 发生时运行。视图生成步骤的性能不仅取决于模型的大小，还取决于模型的互连程度。如果两个实体通过继承链或关联连接，则称它们是连接的。同样，如果两个表通过外键连接，则它们是连接的。随着模式中连接的实体和表的数量增加，视图生成成本也会增加。
杂乱的设计师界面：
当您从大型数据库模式生成 Edm 模型时，设计器界面上充斥着大量实体，很难理解实体模型的总体外观。如果您对实体模型没有很好的了解，您将如何自定义它？
Intellisense 体验不是很好：
当您从包含 1000 个表的数据库生成 Edm 模型时，您最终将得到 1000 个不同的实体集。想象一下，当您输入“上下文”时，您的智能感知体验会如何。在 VS 代码窗口中。
混乱的 CLR 命名空间：
由于模型架构将具有单个 EDM 命名空间，因此生成的代码会将类放置在单个命名空间中。
有关更详细的讨论，请查看在实体框架中使用大型模型 - 第 1 部分 http://blogs.msdn.com/b/adonet/archive/2008/11/24/working-with-large-models-in-entity-framework-part-1.aspx?wa=wsignin1.0
解决方案：
虽然没有现成的解决方案，但它建议您应该模型中自然断开的子集这意味着，根据您的领域模型，您应该提出不同的领域模型集，每个域模型都包含相关对象，而每个集都是不相关的并且与另一个集断开连接。中间没有外键可能是分离的好兆头。这是有道理的，因为在大型模型中，您的应用程序通常不需要将数据库中的所有表映射到一个实体模型才能工作。
即使这种分离不是 100% 可能的（这意味着某些表的子集具有指向数据库中其他表的外键），它仍然鼓励您将它们分开。当您这样做时，您必须承担适当设置外键的责任。没有导航属性允许您获取表示该外键的实体。当然，如果需要，您可以在其他容器中手动查询该实体。
此外，有关如何在重用类型时将一个大型实体模型拆分为较小实体模型的一些提示和技巧，请查看：在实体框架中使用大型模型 - 第 2 部分 http://blogs.msdn.com/b/adonet/archive/2008/11/24/working-with-large-models-in-entity-framework-part-2.aspx
关于你的问题：Order and Customer属于同一自然域，应保存在同一 EDM 中。就像我说的，您可以将它们分散在 2 个不同的实体数据模型上，但是您必须负责设置适当的外键，否则您将得到运行时异常，同样的道理，Customer and Product应保存在单独的实体数据模型中。遵循这些规则，您可以在数据访问层中提出明确定义的域集设计。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
