个人觉得这个结构只适合很小的项目或者不太复杂的项目，因为zend Library是包含在项目里面与web_root同一级，假如我需要创建一个helloword_2的项目，那么不得不再复制一个同样的文件夹结构，Zend Library将会有两份，如果有十几个或者更多的这样的工程，那么Library将会有很多，Zend Framework是个很活跃的框架，没准哪天就升级了好几个版本，如果你需要升级或者打补丁，那么就会烦死。

当然在application下新建一个modules文件夹，将各个功能放在这里也是一个方法，但是你肯定不想一堆一点关联都没有的项目堆在一起，比如豆瓣的九点和群组，这两个几乎没有任何关联，当然实际应用中还有一个非常重要的用户模块。每个应用只做自己该做的事情，才会最大限度的独立很分散，无论是为了负载均衡进行多点发布还是代码维护都非常有用。而且所有的应用都通过一个入口（web_root中的index.php）和同一个分配器来处理，显然并发能力和容错能力都会下降，稍微有点差错，所有的应用都挂了。入口，分配器等属于全局的东西会影响所有应用，事实上可能很多东西对别的应用毫无用处，但是又有很多应用又需要，这时候就产生了浪费。

不过Zend Framework是个自由度很高的框架，可以自己定义一些东西，让Library从项目中独立出来，与项目目录平级，每个项目拥有自己的独立名称、web_root、入口和分配器，这样做可以为每个项目单独添加Vhost，升级内核（zend Library）也只要升级一个即可，有更高的自由度和松散度。所以我推荐如下的结构：

图中的test是一个项目名，请注意是项目名，不是功能名称，在application中你可以为这个项目建立很多modules，我在图中没有建立这样的文件夹，你可以建立test2，test3……项目，这些项目毫不相关，或者关联度很低，比如用户就得是一个独立的项目，其他的功能可能是一个或者几个独立的项目，事实上还有更好的目录结构，我是从神仙那里学过来的.在controllers文件夹中建立front， backend， amdin，三个文件夹，在view中也建立对应的文件夹，放在front中的内容不做任何限制，backend中需要登录，admin就不用说了，渲染views中对应文件夹的模板，全局进行权限控制，似乎神仙这样的结构不能提供精细访问权限，zend Framework提供了这样的精细权限控制。

如果你的代码要改成左图的结构，需要改动一些代码，首先是需要在入口文件中注册这些目录的位置代码如下：

       define('APP_PATH', dirname( dirname ( __FILE__ ) ) );
	define('LIB_PATH', dirname( APP_PATH ) . "/library");
	date_default_timezone_set('Asia/Shanghai');
	//directory setup and class loading
	set_include_path('.' . PATH_SEPARATOR . LIB_PATH
				. PATH_SEPARATOR . APP_PATH . '/application/models'
				. PATH_SEPARATOR . get_include_path());
 
	include  "Zend/Loader.php";
	Zend_Loader::registerAutoload();
	//set up controller
	$frontController = Zend_Controller_Front::getInstance();
	$frontController->throwExceptions(true);
	$frontController->setControllerDirectory( APP_PATH . '/application/controllers');
	Zend_layout::startMvc(array('layoutPath'=>; APP_PATH . '/application/layouts' ) );
	//run
	$frontController->dispatch();

这么一堆代码中其实最主要的就是最开始两句，获取当前项目的磁盘路径和Library，然后告诉程序，在你的action文件你需要一个在渲染模板前告诉程序去哪里取得相应的模板文件，默认是在View/script/中，zend Framework在渲染模板前提供一个抽象方法 postDispatch，可以override之：

    function postDispatch() {
       $this->view->addScriptPath(APP_PATH. '/application/views/');
     }

需要改变的代码就这么两处，实际上还可以做得更好点，将这个postDispatch写入helper中，这样就不需要在每个action文件中重复这段代码了

您可能也喜欢：

Zend Framework学习笔记（一）

php从业者特征

Why PHP Hacks?

关于PHP最佳实践方法的两个PPT

初学PHP的18个基础例程

无觅

2、路由  ，路由特性是由 Zend_Controller_Router_Interface实现的，由Zend_Controller_Router_Rewrite提供URL重写功能。

3、分配器 ，Zend_Controller_Dispatch_Standard类控制

4、Actiong ，所有的动作都是源自于Zend_Controller_Action这个抽象类，Zend_Controller_Action提供了两个级别的处理请求，一个是init(),另外一个是preDispatch()

init()函数是在控制器被调用的时候触发的  ，如果该控制器被调用多次，那么preDispatch（）将被调用多次，而init（）只调用一次。

5、Response（响应）

Zend_Controller_Response_Http 是为编写web程序准备的

Zend_Controller_Response_CLI适应更多的场合

Zend_Controller_Response_Http包含三种信息：header，body和exception（异常）

6、Front Controller Plug-ins（前端控制器插件）

所有的插件都实现于Zend_Controller_Plugin_Abstract这个抽象类，一共有六个事件方法可以被重写。

1)routeStartup()

2)dispatchLoopStartup()

3)preDispatch ()

4)postDispatch()

5)dispatchLoopShutDown()

6)routeShutDown()

您可能也喜欢：

Zend Framework学习笔记（二）

php从业者特征

简单易学的PHP入门教程

PHP记事本程序（三）----持续改进

PHP解析XML文档

无觅