c# - 对 MongoDb 和 Entity Framework 的抽象

Question

由于 Mark Seemann 的这句话，我可能正在执行不可能的任务:

If you have a specific ORM in mind, then be explicit about it. Don't hide it behind an interface. It creates the illusion that you can replace one implementation with another. In practice, that's impossible.

但我想要完成的是通过更改我在启动时的依赖项来使用 MongoDb 驱动程序切换我的 Entity Framework ORM。

但我一直遇到一些问题，即我没有提供足够的灵 active ，或者我的 MongoDb 实现中有太多 new NotImplementedException();。

我的接口(interface)当前结构如下所示:

public interface IReadEntities
{
    IQueryable<TEntity> Query<TEntity>() where TEntity : Entity;
}

public interface IWriteEntities : IUnitOfWork, IReadEntities
{
    TEntity Get<TEntity>(object firstKeyValue, params object[] otherKeyValues) where TEntity : Entity;

    Task<TEntity> GetAsync<TEntity>(object firstKeyValue, params object[] otherKeyValues) where TEntity : Entity;

    IQueryable<TEntity> Get<TEntity>() where TEntity : Entity;

    void Create<TEntity>(TEntity entity) where TEntity : Entity;

    void Delete<TEntity>(TEntity entity) where TEntity : Entity;

    void Update<TEntity>(TEntity entity) where TEntity : Entity;
}

public interface IUnitOfWork
{
    int SaveChanges();

    Task<int> SaveChangesAsync();

    Task DiscardChangesAsync();

    void DiscardChanges();

    void Reload<TEntity>(TEntity entity) where TEntity : Entity;

    Task ReloadAsync<TEntity>(TEntity entity) where TEntity : Entity;
}

但是通过这个实现，我已经无法完成“完整”的 MongoDb 实现，因为 MongoDb 不使用工作单元模式或两阶段提交。

然后我想将 IUnitOfWork 移动到 IWriteEntities 的扩展方法中，但后来我丢失了连接到实体上的 DbContext框架实现，我不会在静态方法中使用服务定位器模式。

所以我最后的手段是问有没有我还没有尝试过的黄金之路？或者我应该简单地再创建两个接口(interface):

public interface IEntityFrameworkWriter : IWriteEntities, IUnitOfWork {} // Move IUnitOfWork out of IWriteEntities

public interface IMongoDbWriter : IWriteEntities {}

并在我的应用程序中使用这些。但话又说回来，这不是我计划的。感谢您提供任何反馈。

爆头

Answer 1

switch my Entity Framework ORM out with the MongoDb driver just by changing my dependencies on startup.

这比单纯的接口(interface)问题要深入得多。这将导致一场灾难性的哲学冲突。

MongoDB 应该与写入量较大、通常是非规范化的数据结构一起使用。您的索引、插入和工作程序很复杂，查询也很简单。架构必须经过精心设计以支持您需要的查询，而不是基于对象之间的关系。

经典的 SQL 方法是相反的:仅靠关系就足以产生良好的数据结构，架构很简单(尽管很大)，没有用于最终一致性的工作人员，但是查询非常复杂，通常是因为属于一起的必须拆分到两个或三个表中。这就是为什么事务和工作单元是典型 SQL 环境中的关键，而 MongoDB 甚至不支持它们。

当然，我是在简化:这里有一个范围，您可以将 MongoDB 和 RDBMS 都用作简单的键值存储；您可以在 SQL 中提出非规范化的数据结构，并且可以在 MongoDB 中保留大量关系。但是您的 MongoDB 不会学习参照完整性或(分布式)事务，并且您的 SQL Server 不会放弃 SQL。

但是，您使用的抽象越多，它们获得的支持越广泛，您就越会将这些关键原则隐藏在臃肿的代码后面。我想一般可以这么说:一个足够抽象的接口(interface)，任何技术都可以实现，但它会让用户感到沮丧。