PHP依赖注入和复杂性

我已经研究了很多关于依赖注入理论的知识，除了它似乎在某些场景中引入了复杂性/膨胀这一事实之外，它非常有意义

首先，假设DI容器实例从未传递到任何对象中。糟糕的做法和所有这些

例如：考虑一个用户类，该类与特定用户在系统中创建的所有其他业务对象相关。 如果要删除用户实例，则还必须删除所有相关对象，即记录、文件、图像等。这是否意味着每个依赖项的实例都将被注入到用户实例中，以允许查找和删除所有相关对象？i、 e.必须传入ImageMapper或ImageMapperFactory的实例，才能删除被删除的用户实例创建/上传的所有图像

如果不是，那么这样的场景是应该使用服务定位器的好例子吗

我发现在文章和教程中反复提到，程序员必须避免在任何类中使用new，比如瘟疫。但是，对于可能需要创建各种视图等的控制器实例，这真的可行吗

---

至少就DI而言，如果能举一个具体的例子来说明如何遵守坚实的咒语，我们将不胜感激。。。它清楚地说明了如何将所有必需依赖项的实例填充到控制器类中，或者如何找到或创建此类依赖项的最佳实例？

我不懂PHP，但我会尝试解释一些事情，这样您的问题就不会被忽略，请耐心听我说-

我发现依赖项注入通过将应用程序分层来实现最佳效果：

表示层-提供与应用程序交互的一些用户界面。 业务逻辑/服务层—应用程序的实际行为。 持久性/数据访问层—存储/读取后端数据的层，尝试搜索存储库模式。 这些层都使用域模型以结构化的方式相互传输数据。例如，这些模型可以是用户和图像

当应用程序逻辑声明用户图像在用户被删除时将被删除时，您将需要中间层的业务逻辑。业务逻辑层调用数据访问层以删除实体

让我们演示一下如何使用Python，我希望您能够阅读

# Define a class that manages users.
class UserService:
    # A constructor accepting dependent DAL instances.
    def __init__(self, user_repo, image_repo):
        self.user_repo = user_repo
        self.image_repo = image_repo

    def delete(self, user):
        self.user_repo.delete(user)
        self.image_repo.delete(user.profile_picture)

构造函数中的repo参数是存储库类的实例，这是依赖项注入构造函数注入

---

重要的是要记住，一个对象不会实例化另一个对象，它接受对象的实例。

siebz0r，您已经证实了我在继续研究这个问题时慢慢得出的结论。特别是服务层：我一直对服务层的概念持怀疑态度，因为我确信它违反了Bob叔叔的类/对象名称中的无动词规则。继续…但是，现在很清楚，服务层/方面在MVC结构中有一个明确的位置，模型表示域数据对象，只知道它们自己，即实体中的，服务层处理业务逻辑，如果从逻辑上考虑，这反过来会使瘦控制器和胖模型有意义。fat模型旨在表明/支持单一责任原则imho，并延伸到您不应该只是把车撞坏的想法。从控制器到模型的逻辑，但要分开考虑，这样服务层才有完美的意义。当数据映射器存在时，我仍在考虑存储库模式的相关/适用性。存储库感觉有点奇怪，尤其是考虑到您经常处理域对象的多个实例的获取和表示，但您主要是操作，即一次只对一个实例进行编辑/更新，因此数据映射器看起来非常适合。最后，存储库的存在似乎意味着关于对象之间关系的多样性/基数的某些事情，例如，UserImage存储库是否意味着每个用户可能与多个图像关联，还是仅与一个图像关联？在RDBMS之外的什么地方可以强制执行这样的基数规则：在服务层还是在域对象模型内部？总而言之，似乎没有理想的解决方案&随着项目的进展，必须做出妥协，希望在项目过程中出现稳定的设计。@Nibbl3r用户有一个映像还是多个映像是业务逻辑。这是使用域模型建模的，并由业务逻辑层实施。业务逻辑包含与业务相关的操作，域模型提供数据格式。