我反对其访问其数据库提供Web服务，并公开通过.NET类的系统开发。我们通常的工作方式是创建每当我们需要访问数据库，并直接使用该实例的Web服务类的一个实例;这当然完全违背了IoC并创建了大部分不可测试的代码。我现在正试图设计一种使用IoC的新标准工作方式，以使我们能够编写（更多）SOLID代码。IOC/SRP的设计问题
我目前的解决办法是这样的（不是真的很好的解释）：
Web服务被包裹在一个DatabaseConnection类存储Web服务对象作为一个受保护的成员并提供访问常用的一些通用数据库调用。
当我需要实际应用程序中的数据库访问时，我从该类派生（调用新类，例如，ApplicationDatabaseConnection），然后在可以调用Web服务的方法中实现所需的数据库交互。
此类应用程序中未直接使用，但提供用于应用程序的不同部分，其中的每一个是通过在顶层等类的控制器/视图模型代表的“连接器”的接口。每当这些应用功能之一是所谓的（例如，从UI）时，将创建相应的控制器对象，并通过我的ApplicationDatabaseConnection对象作为各自的“连接器”的接口的一个实施方式中，这样的数据库访问被适当地封装和去耦在这一点上，如尽我所知。
我的问题是：虽然这是我在自己的代码中发现实际使用ISP（接口隔离原理）的第一种情况（虽然我很难确定这是否实际上是合理使用该概念） ，恐怕这个班可能做得太多，违反了SRP（单一责任原则）。或者“只为一些不同的消费者提供数据库访问权限”是一项单一的责任？
为了也许做出更清楚一点，这里的大致相关的类会是什么样子：
DatabaseConnection
protected m_webservice
public OftenUsedDatabaseAccess()
ApplicationDatabaseConnection : DatabaseConnection, IConnectorA, IConnectorB
public IConnectorA.RetrieveRecords(fieldValue)
public IConnectorB.WriteStuff(listOfStuff)
FunctionAController
private m_IConnectorA
FunctionBController
private m_IConnectorB
我能想到的做的替代品不是真的看起来是理想的，以我满意。
要分割该数据库访问功能，该ApplicationDatabaseConnection类只能是一个工厂类Create方法不同的连接器（后面IConnectorAFactory，IConnectorBFactory接口） - 但真的有没有什么有没有必要工厂模式;没有什么我只知道实例化“控制器”对象。
此外，实际的连接器类基本上也需要衍生DatabaseConnection，因为它们需要相同的基本功能，然后（最迟）整个构造变得相当不祥。
我想我已在我的思想有些点是错误的一步，现在是完全在错误的轨道上。这种解决方案的结构应该是什么样子？任何推动正确的方向将不胜感激。
编辑：
@Tobias的回答让我意识到，我忘了一个重要的细节：有两个不同版本的Web服务的使用几乎相同的能力，而是完全不同的API，这是一个被封装它之所以有。另一个是如果我的逻辑类直接访问Web服务（或通过接口），他们还关心构建Web服务查询的所有细节，这使得更紧密耦合的代码（类型我们一直在生产）并违反了SRP - 因此也是连接器接口的想法。