上或下？

我是一个非常注重视觉的人。我将我的应用程序视为一个层次结构，顶部是根，底部是叶子。

我还了解到，在 DI 系统中，容器不知道其所包含对象的职责/功能。相反，所包含的对象知道它们的上下文，因为上下文（依赖项）被注入。

UP: （非 DI 方式？）
我的事件是否应该从bottom我的等级制度和泡沫向上到他们的父母？例如。我的 GUI 中的一个按钮会调度一个CLICKED事件，由侦听容器捕获，并通过执行适当的操作进行响应。

DOWN: （DI方式？）
我的事件是否应该从top孩子听从父母的安排？例如。 --...好吧，我很难想出这个。我正在思考为所包含的对象调度事件的中介者的思路。

“向上”对我来说似乎很自然，但由于 DI 有一个容器不知道其所包含的对象的行为，所以我不想响应它们的事件。

编辑（澄清）：

我意识到几乎可以让系统的任何部分监听事件，但我想了解 DI 参与者之间的基本关系，以便我可以构建它们properly。我假设人们通常不会只是分散有关他们的程序的事件而不考虑结构关系、依赖关系等。

我的问题源于 DI 系统中的责任放置——注入对象的责任是调用注入器，注入器的责任是为其依赖对象提供服务（这颠倒了非 DI 范式——因此有“反转”之类的同义词）控制”和“依赖倒置”）。这似乎是 DI 的一个非常重要的基本组成部分——责任的转移。我认为调用对象的函数或侦听其事件都是以下示例取决于在另一个物体上。当一个对象基于另一个对象定义自己的行为时，我将其称为依赖关系，因为一个对象知道另一个对象，也知道另一个对象做什么。它在另一个对象的上下文中定义了自己。据我了解，DI 的设置使得注入对象依赖于注入器，因此注入对象有责任了解有关注入器的所有信息。并且注入者不应该有责任了解注入的对象。因此，对于注入器来说，侦听包含的注入对象上的事件在我看来就像是职责的错位，因为这意味着它了解其内容。

请告诉我这是否错误以及如何错误。

依赖注入和观察者模式中的角色分配是正交的关注点。一个对象可以扮演观察者或被观察者的角色，同时可以是组合对象、被组合对象、两者或两者都不是。

考虑一个典型的例子，其中按钮由控件组成。单击该按钮时，它会引发一个 Clicked 事件，该事件由包含的控件响应。在这种情况下，观察对象构成了被观察对象。

现在考虑一个由许多控件组成的屏幕。屏幕可能会引发 Closing 事件，该事件允许组合控件在整个屏幕关闭之前执行自己的清理工作。在这种情况下，被观察的对象构成了观察者。

现在考虑一个由按钮和标签组成的屏幕。单击按钮时，将调用标签的 Clear() 方法。在这种情况下，观察者和被观察者都不构成对方，但两者都是由屏幕对象构成的。

现在考虑一个屏幕，它引发一个它本身订阅的 Closing 事件（也许确保它自己是注册的最终事件处理程序）。当它引发 Closing 事件时，允许任何观察者首先执行他们可能需要的任何操作，然后它处理自己的事件。在这种情况下，观察者就是被观察者。

依赖注入涉及对象如何获取其依赖关系。注入给定对象的依赖项可能包含该对象想要订阅的事件，或者依赖项可能订阅它正在注入的对象。在一个对象被注入另一个对象之后，两个对象如何交互实际上与依赖注入没有任何关系。

EDIT

关于您的澄清部分，我相信我理解您困惑的根源。传统上，对象创建自己的依赖项。依赖注入通过将如何获取依赖关系的知识转移到对象之外来反转获取这些依赖关系的责任。然而，依赖注入不会反转依赖关系。您可能会将依赖注入与依赖倒置原则 http://www.ctrl-shift-b.com/2008/12/examining-dependency-inversion.html。依赖倒置原则确实颠倒了“高级”和“低级”对象之间的依赖关系，但依赖注入只关心如何将依赖提供给给定对象。因此，使用依赖注入不会改变对象之间通常交互的方式。如果在使用依赖项注入之前对象 B 订阅了对象 A 引发的事件（反之亦然），则引入依赖项注入不会改变这一点。