2019独角兽企业重金招聘Python工程师标准>>> 
Zend_Application可谓是Zend MVC框架中几大重要模块之一，入口文件index.php一开始读取的时候就需要加载Zend_Application。
让我们从一个Zend框架项目开始会做些什么操作来分析，
首先
就是会读取index.php文件里面的内容这个毫无疑问，在index.php文件里面有
require_once 'Zend/Application.php';
$application = new Zend_Application(
APPLICATION_ENV,
APPLICATION_PATH . '/config/application.ini'
);
$application->bootstrap()
->run();
这里就是开始加载一些application的配置参数，让我们都看看其做了些什么
$application = new Zend_Application(
APPLICATION_ENV,
APPLICATION_PATH . '/config/application.ini'
);
查看Zend/Application.php 可知道这是开始构造一个类，这个构造函数有两个参数，
&& APPLICATION_ENV :
一个Application的环境，这个就是读取.ini文件下[production],[development : production]等这几个开发环境中我们选择的一个，一般默认我们选择的是[production]
&& APPLICATION_PATH.'/config/application.ini'
: 就是我们外部引入的一个配置文件，这里配置文件的格式还可以是一个数组，一个Zend_Config实例而且还可以是xml,json等格式的文件，但是我们都习惯性使用.ini格式,。
Zend/Application.php该构造函数除了定义环境之外，还初始化了Zend_Load_Autoloader单列，将在ini里面的一些参数进行自动加载配置。
到这里已经创建了Zend_Application实例并配置了一些参数，接下来
$application->bootstrap()就是对其进行引导，查看Zend_Application中bootstrap()方法可得知，Zend将引导方法给了
Zend_Application_Bootstrap_BootstrapAbstract，但是Zend_Application和
Zend_Application_Bootstrap_BootstrapAbstract是聚合关系，两者各有联系并相互通讯。调用bootstrap()方法的时候会实例化
Zend_Application_Bootstrap_BootstrapAbstract的一个子类对象（
Zend_Application_Bootstrap_Bootstrap
），
Zend_Application_Resource这里包含了一系列的引导资源，
引导资源类实现了 Zend_Application_Resource_Resource接口，继承自 Zend_Application_Resource_ResourceAbstract，这些资源都可以在ini文件里面设置，
Zend_Application把bootstrap()方法转发给 Zend_Application_Bootstrap_Bootstrap ，在Zend_Application_Bootstrap_Bootstrap的bootstrap()中，遍历注册了的引导资源的并调用引导的 init()方法。
。
配置文件（一般是configs/application.ini）可以使用并配置的资源基本有一下几项
* Zend_Application_Resources_Db
* Zend_Application_Resources_Frontcontroller
* Zend_Application_Resources_Layout
* Zend_Application_Resources_Locale
* Zend_Application_Resources_Log
* Zend_Application_Resources_Mail
* Zend_Application_Resources_Modules
* Zend_Application_Resources_Navigation
* Zend_Application_Resources_Router
* Zend_Application_Resources_Session
* Zend_Application_Resources_View
Zend_Application_Resources_Frontcontroller
手册里一些配置参数
&& controllerDirectory ： 配置controller的路径，一般在单模块的时候使用
&& moduleDirectory ： 多模块的时候配置模块的入口路径
&& moduleControllerDirectoryName ： 多模块的时候配置每个模块控制器的目录
&& defaultControllerName ： 多模块时候默认控制器的名字，一般是 index
&& defaultAction ： 多模块默认Action的名字，一般也是index
&& defaultModule ： 多模块下默认模块的路径 ，一般是default
&& baseUrl ： 设置基本url一般是自动检测
&& plugins ： 插件的配置
&& params ： 一些额外的参数
一般单模块的话控制器会这样的配置
resources.frontController.controllerDirectory= APPLICATION_PATH
"/controllers"
这也相当于在index.php或者在Bootstrap.php文件的
如果是多模块的话
resources.frontController.moduleDirectory = APPLICATION_PATH "/modules" //将模块指向 application/modules 目录下，必填
resources.frontController.moduleControllerDirectoryName = "controllers" // 指示模块下controller的路径，必填
resources.frontController.
params.prefixDefaultModule = 1 //
当我们使用了模块后，我们在非默认模块的的动作控制器中需要遵循一个防止命名控制冲突的不同的命名协议。因此，在我们的例子中，所有在product模块中的动作控制器Action Controllers都需要增加一个Product的命名空间，例如，Product模块中的detail的动作控制器应当命名成Product_DetailsController，但对于默认模块（default（global） modules）中的动作控制器则不需要，例如，default模块中的detail的动作控制器应该命名成DetailsController，然而，我们通过设置
prefixDefaultModule
变量能够改变这种默认的行为,
通过这样，我们的default模块中的所有动作控制器（如detail动作控制器）都应该加上模块前缀，即Default_(Default_DetailsController，可填
resources.frontController.params.useDefaultControllerAlways = 1 //估计如果没设置的话应该也是一直使用默认控制器，此处不是很明白，可填
resources.frontController.params.displayExceptions = 0 // 显示运行时的错误,可填