5

我刚刚观看了 Julie Lermans 关于在 EF 中使用有界上下文的视频（http://www.pluralsight.com/training/Courses/TableOfContents/efarchitecture），我现在正在尝试找出实现它的最佳方法（使用 POCO） . 我看到的两个选项是要么拥有一个定义所有内容的 edmx 模型，然后手工制作 DbContexts 以包含适当的实体，要么为每个上下文拥有单独的 edmx 模型并使用自动创建的 DbContexts。

有没有人知道哪个是最好的或任何一个的优点/缺点？

恕我直言：对于单个模型，它的类要少得多，代码重用要多得多（尽管这些类是自动创建的，所以实际上它只会是手动复制的额外功能），但我会有很多一个地方的类和需要专门化的类，每个类都必须有不同的名称。例如，客户、客户功能 X、客户功能 B。

使用单独的模型，我可以对上下文中的内容更加严格，因为删除属性不需要是一个全新的实体，并且我可以根据需要命名所有内容（即所有模型都可以使用 Customer 对象，即使它在模型之间有所不同），但现在每个上下文都有完全不同的实体，即使它们都只是映射到同一个表 - 这也可能使在上下文之间传递它们变得更加困难（但这不应该经常需要，否则它表示上下文定义错误）。

4

4 回答 4

1

我们现在正在讨论这个确切的问题，我也看过 Julies 的视频以及研究 DDD。我希望我的数据访问能够反映工作单元，但我们遇到了一个表名不能在多个 EDMX 中使用的问题。

假设我有表 Customer、CustomerOrder、Order、OrderInventory、Item。在一个屏幕上，我只想显示客户信息，因此我的 EDMX 只有客户。现在另一个用例是我为一个客户开出所有发票，在这个用例中我有 Customer、CustomerOrder、Order、OrderInventory 和 Item。我们得到这个例外：CLR 类型到 EDM 类型的映射不明确，因为多个 CLR 类型与 EDM 类型“客户”匹配。以前找到 CLR 类型“A.Customer”，新找到 CLR 类型“B.Customer”。

你们是如何解决这个错误消息的？您是否要重命名在所有 EDMX 文件中重复的每个表？

于 2013-03-21T18:45:13.830 回答
1

我也在尝试有界上下文，并且遇到了模式的（小？）问题。我最初创建了两个上下文，一个用于域数据，一个用于审计类型数据（实体更改审计信息和流程信息）。最初，我发现数据库只从一个上下文创建表而忽略了另一个。我假设从基本上下文派生这两个上下文，

    public class BaseContext<TContext> : DbContext where TContext : DbContext

会生成完整的数据库，但似乎没有这样做。

解决此问题的一种方法是创建一个引用所有实体的“主”上下文，但不将其公开给模型。这工作正常，但现在 db 模式存在一个小问题。

由于我们的支持人员使用 SSMS 来调试系统，我认为按照与有界上下文相同的方式更改架构是一个好主意，因此我在主上下文中指定了架构（OnModelCreating() 覆盖方法与主语境）：

    modelBuilder.Entity<Address>()
            .HasKey(b => new {b.AddressId,b.EffectiveStartDate})
            .ToTable("Addresses", "Esr");

其中“Esr”是架构。但是，在尝试使用有界上下文写入数据时，会发生错误，表明有界上下文正在使用“dbo”模式。我确信有办法解决这个问题。我确实有一种唠叨的感觉，这可能不值得所有的努力。

当然，有界上下文给应用程序带来了更清晰的感觉，我喜欢构建代码以适应域结构的想法，因为这使整体架构更接近规范，并有助于考虑测试。

另一方面，我的程序员同事在针对单个整体上下文进行编码时是否会难以选择正确的实体？

当应用于支持或 UAT 领域时，上下文的分离更加有用，并且这些人必须在整个业务流程方面与应用程序一起工作。

于 2012-10-29T01:55:29.457 回答
0

但是现在每个上下文都有完全不同的实体，即使它们都只是映射到同一个表

这表明您实际上可能不需要多个有界上下文 (BC)。BC 的主要目标是功能内聚，如果您的模型最终在 BC 之间产生大量干扰（即耦合），则可能表明单个 BC 更合适。在隔离不同的 BC 之前，请考虑通过划分为模块（.NET 中的命名空间）是否可以更好地为您的模型提供服务。查看实现领域驱动设计以了解更多信息。

此外，通常情况下，各种查询要求会让人觉得好像有多个 BC 在起作用，而实际上您只需要不同的方式来查看同一个实体。这与将完全不同的实体放在一起非常不同。考虑使用读取模型模式来解决这个问题。

于 2012-10-25T16:50:23.493 回答
0

我建议您阅读有界上下文是什么以及它们试图解决的问题。从有界上下文定义：

明确定义模型应用的上下文。根据团队组织、应用程序特定部分的使用以及代码库和数据库模式等物理表现形式明确设置边界。在这些范围内保持模型严格一致，但不要被外部问题分散注意力或混淆。

拥有一个单一的 EDMX 模型会违反该明确的边界。您可以想象当来自不同环境的团队在同一个 EDMX 模型上工作时可能发生的摩擦。但是，在您的情况下，您可能会觉得上下文之间的明确边界和集成的成本太高。使用共享内核将允许您在上下文之间共享您的 EDMX 模型。

于 2012-10-25T11:59:02.537 回答