4

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

4

2 回答 2

4

不，它不违反 SoC，实际上它鼓励它。

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

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

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

于 2012-10-21T03:21:40.537 回答
4

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

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

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

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

于 2012-10-21T03:16:44.073 回答