.net – 依赖注入 – 它是否违反了关注点？

依赖注入是否违反了与n层架构相关的问题分离？

假设您有以下项目：

MyApp.Data
MyApp.Business
MyApp.Web

如果我使用DI告诉业务层使用哪种数据上下文,这不会违反SoC吗？这意味着UI(MyApp.Web)必须具备数据访问层(MyApp.Data)的知识才能告诉业务层(MyApp.Business)使用哪个上下文,对吧？

public class WebForm {
    public void Save(Object dto) {
        BusinessObject bo = new BusinessObject(Data.MyDataContext);
        bo.ValidateAndSave(dto);
    }
}

我一直认为,在n层架构中,每个层应该只具备下一层(UI到业务,业务到数据)的知识.这不是什么大不了的事吗？

解决方法

一般来说,你是对的.但是,依赖注入往往被认为是“配置”而不是表示层的一部分(即使它通常通常存在于那里).如果您的UI组件被设计为不了解数据层,那么这才是真正重要的.

如果您正在设计一个可测试的系统,那么业务和数据层应该独立于UI,但必须要配置它们.您可以创建另一个名为MyApp.Configuration的层来完成所有这些,但是大多数人发现这是过度工程的.

重要的是您的组件是否设计得很好,而不是UI是否具有其他层的一些配置知识.

它与Web.Config中的应用程序设置没有什么不同.毕竟,除非您使用面向服务的体系结构,否则一切都在同一个进程中运行在同一个计算机上.如果您使用的是SoA,那么您可以在各自的服务器上配置各个部分.