依赖注入是否违背了关注的分离问题，因为它与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方法中，您可以通过使用从外部注入的实例（无论是手动还是通过容器）使用该方法，但始终在应用程序生命周期的某个根节点使用该方法