Zend框架的模块化方法背后有很好的逻辑吗？

Question

Zend框架发展非常快，我们都同意并且在尝试Zend Framework的模块化结构时我们都感到惊讶，如果要具体的模块引导 - 模块的所有引导文件都在无论我们是否正在使用/访问该模块，都要开始。据我所知，模块引导程序像插件一样执行到主Bootstrap。但另一方面，我发现ZF的实现非常复杂，并且非常尊重设计模式。

所以在开始模拟Lazy Load / Bootstrap之前，我想在引导方面有一个客观的想法

- 那么ZF中的初始模块引导是否有一个坚实的逻辑，或者是否应该更改为延迟/按需引导？

我知道问题非常含蓄，所以让我再说一遍

例如，在模块化应用程序中，我们希望为每个模块提供单独的初始配置（如单独的布局），并且引导程序是“进行初始配置的地方”的范例，对吧？但是如果我们按照Zend Documentation所说的方式放置初始化/配置，那么我们的应用程序会加载每个模块引导类中为每个请求设置的所有初始化。（我只是一个访客，当我请求管理引导时将被执行，虽然在后台） - 它几乎捣毁了系统。

据我所知，这个想法有两种方式可以流动

1. 在模块中引导一些只与整个系统互补的东西 （几乎看不出它是什么）
2. 使用帮助Action插件更改模块引导的方式，或者扩展处理boostrapping madule bootstraps的Bootstrap类

我最初的问题是有没有任何逻辑可以遵循第一个选项，第二个选项会是一个不错的选择吗？

Answer 1

是。它基于调度过程。你无法分辨在引导时你需要哪一个。模块bootstraps有一个优点 - 您不需要将模块代码插入主引导程序 - 它使模块更“自包含”。

模块取决于

• 请求
• 选择路线
• 如果是的话。 _forward（）被称为

但是你可能想为每个模块添加你的路由，注入你自己的disatcher等。这一切都需要在创建请求对象之前完成。这就是为什么所有的引导都是在开始时启动的。

在理想情况下，您的引导程序不应包含重复代码或添加任何严重的开销。您可以从其他启动的bootstraps中恢复资源，因此不存在db adapter或view等对象的副本。