c# – 界面隔离和单一责任原则的困境

在这里,我有一些示例,我将一些接口拆分为更小,更直接的接口：

public interface IDataRead
{
    TModel Get<TModel>(int id);
}

public interface IDataWrite
{
    void Save<TModel>(TModel model);
}

public interface IDataDelete
{        
    void Delete<TModel>(int id);
    void Delete<TModel>(TModel model);
}

我略微简化了(有一些where子句阻碍了可读性).

目前我正在使用SQLite,但是,这种模式的优点在于,如果我选择不同的数据存储方法(例如Azure),它将有希望让我有机会更适应变化.

现在,我有一个针对每个接口的实现,这里是每个接口的简化示例：

public class DataDeleterSQLite : IDataDelete
{
    SQLiteConnection _Connection;

    public DataDeleterSQLite(SQLiteConnection connection) { ... }

    public void Delete<TModel>(TModel model) { ... }
}

... 

public class DataReaderSQLite : IDataRead
{
    SQLiteConnection _Connection;

    public DataReaderSQLite(SQLiteConnection connection) { ... }

    public TModel Get<TModel>(int id) { ... }
}

// You get the idea.

现在,我遇到了将它们整合在一起的问题,我确信一般的想法是创建一个使用接口而不是类(真正的实现)的Database类.所以,我提出了这样的事情：

public class Database
{
    IDataDelete _Deleter;
    ...

    //Injecting the interfaces to make use of Dependency Injection.
    public Database(IDataRead reader,IDataWrite writer,IDataDelete deleter) { ... }
}

这里的问题是我应该如何向客户端公开IDataRead,IDataWrite和IDataDelete接口？我应该重写方法重定向到接口吗？像这样：

//This feels like I'm just repeating a load of work.
public void Delete<TModel>(TModel model)
{
    _Deleter.Delete<TModel>(model);
}

突出我的评论,这看起来有点愚蠢,我把很多问题分成很好的,分开的实现,现在我把它们全部重新组合在一个巨型课程中.

我可以将接口公开为属性,如下所示：

public IDataDelete Deleter { get; private set; }

这感觉好一点,然而,不应该期望客户必须经历决定他们需要使用哪个接口的麻烦.

我完全忽略了这一点吗？救命！