我反對其訪問其數據庫提供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 - 因此也是連接器接口的想法。