以下是老王梳理的内容，bootstrap对于ZF来说非常重要，很大一部分人的程序损耗，都在这里。。。。
原文地址：http://hi.baidu.com/thinkinginlamp/blog/item/419f36d34b68c40a3af3cfc9.html
说点题外话，单就框架而言，对我而言使用CakePHP要比使用Zend Framework顺手得多，不过最近CakePHP陷入了多事之秋，Phpnut，Gwoo，Nate彻底闹僵，Gwoo和Nate选择离开，据坊间传闻他们已经开始另立门户，稍后会释出一个CakePHP的衍生框架：Lithium。虽然CakePHP官方已经表态会一如既往的继续前进，但毫无疑问在众多开发者眼中，CakePHP的前景已经不再明朗，其是否能继续保证PHP框架领头羊的地位也越发充满疑问。
之所以说了这么多题外话，就是为了说明一点，对于广大PHPer而言，过多局限于一种框架之上本身就是一种强耦合，未来是不可预期的。所以我打算在继续使 用CakePHP的同时，适当向Zend Framework倾斜，如果Lithium不错的话，也会在我未来学习计划之中占有一席之地。
言归正传，新版的Zend Framework引入了Zend_Application，把Bootstrap进行的规范化的封装，一个典型的Application的Bootstrap文件大致如下：
class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
protected function _initAutoloader()
{
$autoloader = new Zend_Application_Module_Autoloader(array(
'namespace' => 'Application',
'basePath' => APPLICATION_PATH,
));
return $autoloader;
}
}在Bootstrap中，所有以_init开头的方法被当做资源方法自动运行，如果方法有返回值的话，还会被作为资源保存。资源方法不是唯一配置资源的方 式，为了避免重复编码，框架包含了若干现成的资源插件，可以在配置文件里通过简单设置就可以达到相应的功能，一个典型的配置文件如下所示：
return array(
'bootstrap' => array(
'path' => APPLICATION_PATH . '/Bootstrap.php',
),
'resources' => array(
'modules' => array(),
'frontController' => array(
'controllerDirectory' => APPLICATION_PATH . '/controllers',
'moduledirectory' => APPLICATION_PATH . '/modules',
),
),
);resources部分的modules和frontController就是资源插件。其中modules资源开启了系统的模块功能。比如说你有一个admin模块的话，那么对应的也可以有一个它自己的Bootstrap类：
class Admin_Bootstrap extends Zend_Application_Module_Bootstrap
{
}需要说明的一点是Modules的Bootstrap里一般不再需要类似前面的_initAutoloader资源方法，这是因为从父类 Zend_Application_Module_Bootstrap里已经通过继承自动执行了以模块名为命名空间的Autoloader操作。
在使用Modules的Bootstrap时，有一点需要注意的是系统会把所有模块的所有资源方法统统初始化一遍，打个比方来说，如果你有一个Blog模 块，还有一个Forum模块，每个模块使用各自独立的数据库配置，都有一个自己的_initDb方法，那么即便是我们单独访问Blog或者Forum中一 个模块，系统还是会把两个数据库都连接一遍，这无疑是低效的。但也不能就此认为这是Zend Framework的设计错误，问题的根源在于我们划分模块的粒度大小，如上所示，Blog和Forum不应该以Module的形式存在，而应该以 Application的形式存在。如此一来仅需要在Application层次的Bootstrap中执行一次数据库连接即可。
Zend Framework的文档虽然看似详细，但很多细节都没有说明，比如说View助手缺省就会加载，这一点可以在 Zend_Controller_Front中看到对Zend_Controller_Action_Helper_ViewRenderer的调用，所 以最好在使用时自己扎到源代码里查阅。
