c# - Entity Framework 6.0 从 POCO 解耦实现

Question

假设我有几个基本对象和接口(interface):

interface ICar
{
  int Id { get; set; }

  int DriverId { get; set; }

  IDriver Driver { get; set; }
}

class Car: ICar
{
  int Id { get; set; }

  [ForeignKey("Driver")]
  int DriverId { get; set; }

  IDriver Driver { get; set; }
}

如果我使用“Driver”而不是“IDriver”的实现类，一切都会很愉快(所以让我们忽略我缺少所有其他值的额外配置)，但是使用 IDriver 最终会出现错误:

The property 'Driver' cannot be configured as a navigation property. The property must be a valid entity type and the property should have a non-abstract getter and setter. For collection properties the type must implement ICollection where T is a valid entity type.

据我所知，实体实际上并不以任何方式支持这一点，我的选择是:

• 很难将我的 POCO 接口(interface)耦合到实体，给可测试性和可移植性带来了麻烦，welp。
• 在我的 POCO 和实体对象之间添加一个过渡层 (bleh)。
• 抛出实体，通过一些支持这一点的讨厌的 Linq2SQL 实现来解决这个问题(尽管 Linq2SQL 提示 EntityRefs，但它与 EntitySets 和接口(interface)一起工作得很好!)。
• 找到另一个 ORM，使我能够从我的实现数据提供者中正确地抽象出我的 POCO。

或者我在这里遗漏了什么吗？

Answer 1

您没有将 POCO 耦合到 EF，这是相反的方式并且完全合法，因为域对象是您应用程序的基本构建 block 。类似于整数、字符串等...您不会“接口(interface)” int，对吗？任何时候你扔掉 EF 而拿 NH，例如，这根本不会影响你的 POCO。

现在，另一方面，自定义 DbContext 和业务类是您需要为其创建接口(interface)的东西。这样您就可以出于测试目的模拟它们并更改实现。

还有一件事 - 不要让自己陷入在自写数据访问层中从业务层抽象 EF 的想法。虽然这是可以实现的，但它也会对您的业务层实现施加大量限制。您将不得不发明 self 折磨技术来编写查询，否则这将占用您 5 秒的时间。

在我看来，理想的依赖关系图，是我经过大量实验得出的，现在看起来像这样

域对象、业务和上下文接口(interface)是应用程序的核心。其他层相互独立，因此可测试。

请注意，这里的业务层依赖于 EF，如果我决定从 EF 切换(非常怀疑)，我将不得不移植我的业务类。我认为，这是一个不太可能发生的事件，并且为 EF 在我的商务类(class)中给我带来的所有舒适感付出的代价很小。