代码之家 › 专栏 › 技术社区 › janhartmann

MongoDb和实体框架上的抽象

abstraction dependency-injection mongodb entity-framework c#

janhartmann · 技术社区 · 11 年前

我可能无法执行任务,因为 Mark Seemann :

如果你心中有一个特定的ORM,那么就要明确它将其隐藏在界面后面。它制造了一种错觉,你可以用另一个实现替换一个实现。实际上,这是不可能的

但我试图实现的是,通过改变启动时的依赖关系,将我的实体框架ORM与MongoDb驱动程序进行切换。

但我不断遇到问题,我没有提供足够的灵活性,或者只是有太多 new NotImplementedException(); 在我的MongoDb实现中。

我的接口当前结构如下:

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 它连接到实体框架实现中,我不会在静态方法中使用服务定位器模式。

所以,我最后的办法是问,是否有我尚未尝试过的黄金道路?或者我应该简单地再创建两个接口:

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

public interface IMongoDbWriter : IWriteEntities {}

并在我的应用程序中使用这些。但话说回来,这不是我计划的。任何反馈都很感谢。

头部爆炸

1 回复 | 直到 11 年前

mnemosyn 11 年前

只需更改启动时的依赖关系,就可以使用MongoDb驱动程序切换我的实体框架ORM。

这远不止是一个问题接口这将导致哲学的灾难性冲突。

MongoDB应该与一些写量较大的、通常是非标准化的数据结构一起使用。您的索引、插入和工作程序很复杂,查询也很简单。必须仔细设计模式以支持您需要的查询, 不基于对象之间的关系。

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

当然,我在简化:这里有一个范围,您可以滥用MongoDB和RDBMS作为简单的键值存储;您可以在SQL中创建一个去规范化的数据结构,并且可以在MongoDB中保持大量的关系。但是MongoDB不会学习引用完整性或(分布式)事务,SQL Server也不会放弃SQL。

但是,你使用的抽象越多,支持范围越广,你就越会把这些关键原则隐藏在臃肿的代码后面。我认为人们通常可以说:任何技术都可以实现足够抽象的界面,但这会让用户感到沮丧。