Question

依赖注入是否违反了与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到业务，业务到数据）的知识。这不是一件大事吗？

Answer 1

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

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

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

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

Answer 2

不，它没有违反SoC，事实上它鼓励它。

问题在于，在您的示例中，您不使用DI，至少在UI中。您让WebForm显式构建它需要的对象，而不是注入这些依赖项。

主要思想是在应用程序中创建一个中央引导程序，以创建根对象，从而获取依赖项，而依赖项又是从其他依赖项构建的，依此类推。鉴于手动操作非常痛苦，您可以依靠DI容器自动使用约定或通过配置，或两者兼而有之。

因此，在您的示例中，您将使用DI容器构建WebForm，并且您将指定依赖于IBusinessObject的依赖项，而IBusinessObject又依赖于DataContext来对这些实体执行操作并从dto创建它们。然后在Save方法中，您可以通过手动或通过容器使用从外部注入的实例来使用它，但始终在应用程序生命周期的某个根点

依赖注入 - 它是否违反了关注点？

2 个答案: