实体框架中的接口(接口中的接口)

Question

我在实体框架中有两个实体。现在，我想通过将DAL实体的接口放到域中来分离它们。

因此，最终结果将是：

DAL

• Person : IPerson (EF实体)
• Book: IBook (EF实体)

域名

• IPerson
• IBook

• 接口(文件夹)

​

• Person (域实体)
• Book(域实体)

现在的问题是，我的Dal.Person应该有一本虚拟的书还是IBook？DAL.Person、IPerson和Domain.Person应该是什么样的(给我一个很小的接口示例)

Answer 1

EF不支持使用接口，因此如果要将public virtual IBook ...用作EF处理的导航属性，则不能在Person实体中使用它。

Answer 2

你问题的答案完全取决于你在这里的目标。

如果您创建域级接口的基本原理是，您可能(在稍后的某个阶段)将DAL从实体框架切换到完全不同的东西(例如第三方web服务，或者可能是xml序列化)--那么您的目标将是将域和DAL之间的任何具体逻辑完全分离开来。

在可能的情况下，您希望您的域在域实体/接口上操作，而DAL在实现数据访问中指定的接口的同时对DAL实体/接口进行操作。

因此，DAL对象DAL.Person应该包含一个Book，并在域级别上从IPerson接口实现。

我将按要求举几个例子：

#region Domain Objects


    public interface IPerson
    {
        List<IBook> Books { get; private set; }
    }

    public interface IBook
    {
        string Name { get; private set; }
    }

    #endregion

    #region DAL/Entity Framework Auto Generated classes

    public class Person : IPerson
    {
        public List<Book> Books {get; private set;}
    }

    public class Book : IBook
    {
        public string Name { get; private set; }
    }

  #endregion

与Jodrells的评论相反，我认为如果需要“热交换”数据访问层，那么DataAccess层就有可能实现域层中描述的接口契约。

老实说，我很少看到这种需求--通常最好是扩展自动生成的实体框架类(通过partial)并传递应用程序，通过指定域对象和契约本身来删除所需的复制。因此，本质上，实体框架类成为域层的。

我应该指出，您应该按照上面的注释使用POCO类。

Answer 3

我还没见过用来解耦EF的界面。我知道它们用于依赖注入的解耦，但可能在幕后使用EF的情况太多了(动态代理、更改检测)。

我建议实现一个存储层。

步骤1

首先从域中最简单的模式模型(Person和Book)和DAL层中的EF开始，首先使用代码的标准EF过程。EF在DbSet<Person>和DbSet<Book>中实现存储库特性(当然，这种存储库类型锁定在EF中)。

让一个可交付的应用程序与此模式工作，您可以演示功能相当快。这使您可以专注于应用程序逻辑，而不必过多地担心持久性。

步骤2

在域和DAL之间放置一个或多个存储库类。将对DbSet<Person>和DbSet<Book>的域调用替换为对存储库中的IQueryable<Person>和IQueryable<Book>的调用。存储库集合最初只是指向EF DbSet<>集合。

在存储库中也实现Save()。最初，它只调用DbContext.SaveChanges()。

检查功能保持不变。

步骤3

用新DAL中任何等价的内容替换存储库IQueryable<>的源。这可能是棘手的，也可能不是棘手的，这取决于新DAL的形状。

我遵循这种过程--从XML序列化的DAL开始，将其移动到EF，将一个表重构回本地XML文件，下一步是将另一个表重构为ESB上的web服务。

BTW，您提到用SQL替换EF以提高性能。我们发现EF对于大容量插入比较慢，因为它使用逐行的样式。

为了解决这个问题，我在基于EF的存储库中实现了SqlBulkCopy (而不是对EF进行大规模替换，因为EF还有我们非常喜欢的其他特性)。它很快，但需要一段时间来拼凑在一起。