Zend 框架的模块化方法背后有良好的逻辑吗？
Zend 框架发展得非常快，我们都同意，并且在尝试 Zend 框架的模块化结构时我们都感到惊讶，具体来说是模块的引导 - 模块的所有引导文件都会在开始时执行我们是否正在使用/访问该模块。据我记得，模块引导程序像主引导程序的插件一样执行。但另一方面，我发现 ZF 的实现非常复杂，并且在编写时非常尊重设计模式。
因此，在开始尝试模块延迟加载/引导程序之前，我想对引导方面有一个客观的思考
--ZF 中的初始模块引导是否有坚实的逻辑背后，或者应该将其更改为其他内容像惰性/按需引导？
我知道问题是相当隐含的，所以让我给出更多，
例如在模块化应用程序中，我们希望为每个模块（如单独的布局）和引导程序有一个单独的初始配置是“进行初始配置的地方”的范例，对吧？但是，如果我们按照 Zend 文档所述的方式放置初始化/配置，那么我们的应用程序会加载每个请求的每个模块引导类中设置的所有初始化。（我只是一个访客，但当我请求某些管理员引导程序时将被执行，尽管是在后台） - 这几乎破坏了系统。
据我所知，这个想法可以通过两种方式流动
- 到模块引导程序中，这些东西只是对整个系统的补充 （几乎看不出它是什么）
- 要改变使用帮助操作插件引导模块的方式，或者扩展处理引导 Madule 引导程序的 Bootstrap 类
，我最初的问题是是否有任何逻辑可以遵循第一个选项，第二种选择会是一个不错的选择吗？
Zend framework is pretty fast growing, we all agree and we all had been surprised while trying out the modular structure of Zend Framework, if to be concrete the bootstraping of the modules - all the bootstrap files of the modules are executed in the beginning no matter if we are using/accessing that module or not. As far as I remember the module bootstrap gets executed like plugin to the main Bootstrap. But on the other hand I find implementation of ZF very sophisticated and written with great respect to design patterns.
So before going and stumbling the Module Lazy Load/Bootstrap, I would like to have a objective thought on the bootstrapping aspect
-- So does the initial module bootstraping in ZF have a solid logic behind it or should it be changed to something like lazy/on demand bootstrapping?
I know question is pretty implicit , so let me give some more
for instance in a modular app we want to have a separate initial configurations for each module(like a separate layout) and the bootstrap is a paradigm for a "place to do initial configurations ",right? But if we place initialization/configurations in the way Zend Documentation says, then our application loads all the initializations that have been set up in every module bootstrap class for every request.(I'm just a guest and still when i request something admin bootstrap will be executed, though in the background) - it is pretty much trashing the system.
as far as I see there are two ways the idea can flow
- to have in the module bootstrap things that are only complementary to the whole system
(pretty much don't see what it can be) - To change the way modules bootstrapped with a help Action plugin or extending the Bootstrap class that deals with boostrapping the madule bootstraps
And my initial question was is there any logic to follow the first option, and would the 2nd option will be a good choice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的。它基于调度过程。在引导时你无法判断你需要哪一个。模块引导程序有一个优点 - 您不需要将模块代码插入主引导程序 - 它使模块更加“独立”。
模块取决于
但是您可能想为每个模块添加路由，注入您自己的调度程序等。这一切都需要在创建请求对象之前完成。这就是为什么所有引导程序都是从一开始就启动的。
在理想情况下，您的引导程序不应包含重复代码或增加任何严重的开销。您可以从其他启动的引导程序中检索资源，这样就不会有数据库适配器或视图等对象的副本。
Yes. It's based on the dispatch process. You can't tell which one would you need in the time of bootstraping. Module bootstraps has one advantage - that you don't need to insert module code to the main bootstrap - it makes modules more "self-contained".
Module depends on
But you might want to add your routes for each module, inject your own disatcher etc. And this all needs to be done before creating the request object. That'S why are all bootstraps initiated in the begining.
In ideal case, your bootstrap should not contain repetitive code or add any serious overhead. You can retieve resources from other initiated bootstraps so there are no copies of objects like db adapter or view.