MongoDb和實體框架的抽象

Question

由於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 {}

並在我的應用程序中使用它們。 但話說回來，這不是我的計划。 任何反饋都表示贊賞。

頭探索

Answer 1

只需在啟動時更改我的依賴項，就可以使用MongoDb驅動程序切換我的實體框架ORM。

這比接口的單純問題要深刻得多。 這將導致哲學的災難性沖突。

MongoDB應該使用一些寫重，通常是非規范化的數據結構。 您的索引，插入和工作人員很復雜，查詢很簡單。 必須仔細設計架構以支持您需要的查詢， 而不是基於對象之間的關系。

經典的SQL方法是相反的：單獨的關系足以提供一個良好的數據結構，模式是微不足道的（盡管很大）沒有工人可以實現最終的一致性，但查詢非常復雜，通常是因為屬於一起的東西必須分成兩個或三個表。 這就是為什么事務和工作單元是典型SQL環境中的關鍵，而MongoDB甚至不支持它們。

當然，我正在簡化：這里有一個頻譜，你可以濫用MongoDB和RDBMSes作為簡單的鍵值存儲; 你可以在SQL中提出一個非規范化的數據結構，你可以在MongoDB中保持大量的關系。 但是你的MongoDB不會學習參照完整性或（分布式）事務，你的SQL Server也不會放棄SQL。

但是你使用的抽象越多，它們擁有更廣泛的支持，你就會越多地隱藏這些臃腫的代碼背后的關鍵原則。 我認為通常可以說：足夠抽象的界面可以通過任何技術實現，但它會讓用戶感到沮喪。