依賴注入是否違背了關注的分離問題，因爲它與n層體系結構有關？依賴注入 - 它違背了分離的擔憂嗎？
假設你有以下項目：
MyApp.Data
MyApp.Business
MyApp.Web
如果我使用DI告訴業務層使用的數據上下文，就不會這樣違反的SoC？這意味着UI（MyApp.Web）必須具有數據訪問層（MyApp.Data）的知識才能告訴業務層（MyApp.Business）使用哪種上下文，對吧？我一直以爲，在一個n層架構中，每一層應該只有下一層（用戶界面到商業，商業到數據）的知識。這不是什麼大不了的事？
一般而言，你是對的。然而，依賴注入往往被認爲是「配置」而不是表示層的一部分（儘管它通常通常在那裏居住）。如果您的UI組件設計爲不知道數據層，那麼這纔是真正重要的。
如果您正在設計一個可測試系統，那麼業務層和數據層應該獨立於用戶界面，但必須對其進行配置。您可以創建另一個圖層，稱爲MyApp.Configuration，可以完成所有這些工作，但大多數人認爲這是過度工程。
重要的是您的組件是否設計良好，而不是UI是否具有其他層的某些配置知識。
這與Web.Config中的應用程序設置確實沒有什麼不同。畢竟，除非您使用面向服務的體系結構，否則無論如何，一切都在同一個進程中的同一臺計算機上運行。如果您使用的是SoA，那麼您將在各自的服務器上配置各個部分。
不，它並沒有違反SoC，實際上它鼓勵它。
問題是，在你的例子中，你至少在UI中沒有使用DI。您讓WebForm明確構建它所需的對象，而不是注入這些依賴關係。
主要想法是在應用程序中創建一箇中央引導程序，該程序創建根對象，從而獲得依賴關係，而依賴關係又由其他依賴關係構建，等等。鑑於手動操作是一件非常痛苦的事情，您可以依靠使用約定或通過配置自動執行的DI容器，或者兩者兼而有之。
因此，在您的示例中，您將使用DI容器構造WebForm，並且您將指定依賴關係（比如說，一個IBusinessObject），它依次依賴於DataContext對這些實體執行操作並從dto 。然後，在Save方法中，您可以通過使用從外部注入的實例（無論是手動還是通過容器）使用該方法，但始終在應用程序生命週期的某個根節點使用該方法