2

在我的 ZF2 应用程序中，我使用它Zend\Di\Di来创建我的所有类实例。Zend\Di\Definition\CompilerDefinition使用 APC扫描和缓存 DI 定义。这避免了在运行时使用慢反射扫描类。如果在实例创建过程中出现异常（由于 DI 定义过时），则重新扫描代码，缓存定义，然后重新创建实例。

这在开发过程中非常方便，因为不必为新类或更改的构造函数编写或更改工厂方法/闭包。我的构造函数遵循一定的约定（只有类型提示的参数和单个 $params 数组）以确保依赖注入在不指定其他构造函数参数的情况下工作。

到目前为止，这表现得很好，避免了错误（没有过时的工厂方法），并加快了开发速度。但是，目前在 APC 中扫描的定义为 1.8MB（序列化数组），并且还在增长。由于每次请求都必须从缓存中加载，我担心如果短时间内请求太多，内存会耗尽。不过，我没有负载测试设置来模拟这一点。

我知道推荐的方法是使用 Zend\ServiceManager 并为每个类编写工厂闭包，而不是使用 Zend\Di\Di。但我想这是很多工作，并且在开发过程中很烦人。

你建议在这种情况下重构到 Zend\ServiceManager 吗？

4

2 回答 2

2

我写了一个 ZF2 模块来帮助你解决这个问题：https ://github.com/aimfeld/ZendDiCompiler

ZendDiCompiler是一个 Zend Framework 2 模块，它使用自动生成的工厂代码进行依赖注入。它为您节省了大量工作，因为不再需要编写 Zend\ServiceManager 工厂闭包并手动使它们保持最新。

ZendDiCompiler扫描您的代码（使用 Zend\Di）并自动创建工厂方法。如果工厂方法已经过时，ZendDiCompiler 在后台更新它们。因此，您可以更快地开发，避免由于过时的工厂方法导致的错误，并在生产中体验出色的性能！

于 2013-03-08T09:58:37.107 回答
1

这正是我在博文中所公开的关于Zend\DiRAD的内容。

虽然Zend\Di有利于开发，但它是生产中巨大的内存和性能瓶颈。即使您缓存定义，它仍然使用ReflectionClass和call_user_func_array()操作您的实例。它还必须执行许多对齐注入参数所必需的周边操作：只需查看在array_merge通过Zend\Di.

我编写了一个模块来处理将Zend\Di\Di实例管理器编译为闭包：OcraDiCompiler。它需要一些清理，但它的工作是通过跟踪Zend\Di内部的实例化逻辑来生成代码工厂/闭包。如果您想稍微“恢复”它，我很乐意提供帮助，因为它在我的 TODO 列表中，但现在优先级较低。

无论如何，通过 将实例化逻辑移动到工厂/闭包ServiceManager并不像您期望的那样多，所以不要害怕并尝试一下：您可能会喜欢它。

于 2013-03-01T11:27:09.473 回答