首先，我认为这样做有点荒谬，但是我团队的其他成员坚持这样做，除了“我认为这很愚蠢”之外，我无法提出反对它的好理由。

我们正在尝试做的是创建一个完全抽象的数据层，然后对该数据层进行各种实现。很简单，对不对？输入 Entity Framework 4.1 ...

我们这里的最终目标是程序员(尽我所能，只停留在数据层上)永远都不想暴露给具体的类。除了明显需要实例化工厂之外，他们只希望在代码中使用接口(interface)。

我想实现以下目标:

首先，我们拥有所有接口(interface)的“公共(public)”库，我们将其称为“Common.Data”:

public interface IEntity
{
    int ID { get; set; }
}

public interface IUser : IEntity
{
    int AccountID { get; set; }
    string Username { get; set; }
    string EmailAddress { get; set; }
    IAccount Account { get; set; }
}

public interface IAccount : IEntity
{
    string FirstName { get; set; }
    string LastName { get; set; }
    DbSet<IUser> Users { get; set; } // OR IDbSet<IUser> OR [IDbSet implementation]?
}

public interface IEntityFactory
{
    DbSet<IUser> Users { get; }
    DbSet<IAccount> Accounts { get; }
}

internal class User : IUser
{
    public int ID { get; set; }
    public string Username { get; set; }
    public string EmailAddress { get; set; }
    public IAccount Account { get; set; }

    public class Configuration : EntityTypeConfiguration<User>
    {
        public Configuration() : base()
        {
             ...
        }
    }
}

internal class Account : IAccount
{
    public int ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DbSet<IUser> Users { get; set; } // OR IDbSet<IUser> OR [IDbSet implementation]?

    public class Configuration : EntityTypeConfiguration<Account>
    {
        public Configuration() : base()
        {
             ...
        }
    }
}

public class ImplEntityFactory : IEntityFactory
{
    private ImplEntityFactory(string connectionString) 
    {
        this.dataContext = new MyEfDbContext(connectionString);
    }
    private MyEfDbContext dataContext;

    public static ImplEntityFactory Instance(string connectionString)
    {
        if(ImplEntityFactory._instance == null)
            ImplEntityFactory._instance = new ImplEntityFactory(connectionString);

        return ImplEntityFactory._instance;
    }
    private static ImplEntityFactory _instance;

    public DbSet<IUser> Users // OR IDbSet<IUser> OR [IDbSet implementation]?
    { 
        get { return dataContext.Users; }
    }

    public DbSet<IAccount> Accounts // OR IDbSet<IUser> OR [IDbSet implementation]?
    {
        get { return dataContext.Accounts; }
    }
}

public class MyEfDataContext : DbContext
{
    public MyEfDataContext(string connectionString)
        : base(connectionString)
    {
        Database.SetInitializer<MyEfDataContext>(null);
    }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.Configurations.Add(new User.Configuration());
        modelBuilder.Configurations.Add(new Account.Configuration());
        base.OnModelCreating(modelBuilder);
    }

    public DbSet<User> Users { get; set; }
    public DbSet<Account> Accounts { get; set; }
}

public class UsingIt
{
    public static void Main(string[] args)
    {
        IEntityFactory factory = new ImplEntityFactory("SQLConnectionString");
        IUser user = factory.Users.Find(5);
        IAccount usersAccount = user.Account;

        IAccount account = factory.Accounts.Find(3);
        Console.Write(account.Users.Count());
    }
}

最佳答案

第一个论点是EF不适用于接口(interface)。 DbSet必须使用真实实体实现来定义。

第二个参数是您的实体不应包含DbSet-这是与上下文相关的类，并且您的实体应不依赖此类，除非您将要实现Active Record模式。即使在这种情况下，您也绝对不能访问另一个实体中另一个实体的DbSet。即使包装集，您仍然离EF太近，并且实体永远不会具有访问另一实体类型的所有实体(不仅是与当前实例相关的实体)的属性。

只是为了使EF中的DbSet清楚具有非常特殊的含义-它不是集合。它是数据库的入口点(例如，DbSet命中数据库上的每个LINQ查询)，并且在正常情况下不公开给实体。

第三个参数是每个应用程序使用单个上下文-每个单例工厂只有一个私有(private)实例。除非您正在执行一些单运行批处理应用程序it is definitely wrong。

最后一个论点很实际。为您提供功能而不是在抽象上浪费时间而向您付款，这不会给您(和您的客户)任何业务值(value)。这与证明为什么不应该创建此抽象无关。这是关于证明为什么要这样做的证明。使用它会带来什么值(value)？如果您的同事无法提出具有商业值(value)的论据，您可以直接去产品经理那里，让他使用自己的权力-他拥有预算。

通常，抽象是设计良好的面向对象应用程序的一部分-是正确的。但:

关于c# - 用自定义DbSet/IDbSet包裹DbSet <TEntity>吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7431756/