Zend的MVC機制（一）代碼分析

1

2

3

4

5

6

7

8

9

10

11

12

13

14

<code>$front</code> <code>= zend_controller_front::getinstance();</code>

<code>zend_layout::startmvc(</code><code>array</code><code>(</code><code>'layoutpath'</code> <code>=&gt; usvn_layouts_dir));</code>

<code>$front</code><code>-&gt;setrequest(</code><code>new</code> <code>usvn_controller_request_http());</code>

<code>$front</code><code>-&gt;throwexceptions(true);</code>

<code>$front</code><code>-&gt;setbaseurl(</code><code>$config</code><code>-&gt;url-&gt;base);</code>

<code>$router</code> <code>= </code><code>new</code> <code>zend_controller_router_rewrite();</code>

<code>$routes_config</code> <code>= </code><code>new</code> <code>usvn_config_ini(usvn_routes_config_file, usvn_config_section);</code>

<code>$router</code><code>-&gt;addconfig(</code><code>$routes_config</code><code>, </code><code>'routes'</code><code>);</code>

<code>$front</code><code>-&gt;setrouter(</code><code>$router</code><code>);</code>

<code>$front</code><code>-&gt;setcontrollerdirectory(usvn_controllers_dir);</code>

<code>zend_controller_front::getinstance()-&gt;dispatch();</code>

首先看下zend_controller_front::getinstance是調用單例模式，執行個體化了它的内部屬性_plugins，執行個體化了一個zend_controller_plugin_broker類。

這個類是管理front的插件的類。先看一個front中的方法public function registerplugin(zend_controller_plugin_abstract plugin,plugin,stackindex = null)

意思是如果你有一個自己的插件要插入使用的話，調用這個函數能把你自己的插件委托給zend_controller_plugin_broker使用。

如果你有願望繼續跟下去你會看到注冊插件做的一件最根本的事情就是把request和response放入到你的插件中去(setrequest和setresponse)。

class zend_controller_plugin_broker extends zend_controller_plugin_abstract

這個實作了抽象類zend_controller_plugin_abstract。

zend_controller_plugin_abstract是所有插件的抽象類，所有使用者自己定義的插件或者zend已有的插件都要從這個類繼承。這裡就看到了，前端控制器front就是使用broker作為使用者插件注冊。

這個抽象類可以被實作的函數有：

routestartup: 在路由發送請求前被調用

routeshutdown：在路由完成請求後被調用

dispatchloopstartup:在進入分發循環（dispatch loop）前被調用

predispatch：在動作由分發器分發前被調用

postdispatch:在動作由路由器分發後被調用

dispatchloopshutdown:在進入分發循環（dispatch loop）後被調用

我們還看到了getrequest, getresponse兩個方法，我們可以通過他們分别從控制器中擷取request對象和response對象

好了，扯遠了，回到最開始的代碼，zend_controller_front::getinstance實際上來看做的事情就是注冊了一個broker插件放到$front中。

下面一行代碼

zend_layout::startmvc(array('layoutpath' =&gt; usvn_layouts_dir));

看到zend/layout.php中，startmvc做了兩件事：首先是調用自己的構造函數來執行個體化自己（切記帶着initmvc參數為true），然後是設定參數。

zend_layout的構造函數比較複雜，就跟到裡面看看。首先也是設定傳遞進來的參數options,我們這個例子中是傳遞進來array([layoutpath]=&gt;/var/www/html/usvn/app/layouts)這個array作為options，構造函數就是調用options,我們這個例子中是傳遞進來array([layoutpath]=&gt;/var/www/html/usvn/app/layouts)這個array作為options，構造函數就是調用this-&gt;setoptions($options);

這個setoptions做的事是根據array的每個key，調用this−&gt;setthis−&gt;setkey($val);也就是說，以上面的例子來說，setoptions調用了setlayoutpath("/var/www/html/usvn/app/layouts")

順藤摸瓜，setlayoutpath的功能是設定自己類的this-&gt;_layout為"/var/www/html/usvn/app/layouts"， 然後設定_enable為true；這兩個屬性記住，以後會有使用的。

回退到zend_layout的構造函數，初始化options之後是調用了_initvarcontainer();

這個函數做了這麼個事情：

$this-&gt;_container = zend_view_helper_placeholder_registry::getregistry()-&gt;getcontainer(__class__);

又出現了zend_view_helper_placeholder_registry（我翻譯為：zend視圖助手系統資料庫）

getregistry() 将zend_view_helper_placeholder_registry作為key，zend_view_helper_placeholder_registry類的執行個體作為value注冊到之前見過的zend_registry中。這個類的構造函數就什麼事都沒有。

getregistry()傳回了zend_view_helper_placeholder_registry執行個體，下面調用getcontainer(__class__)。 這裡的__class__是什麼，目前調用的類，自然就是zend_layout了。這裡是getcontainer("zend_layout")

進入到getcontainer裡面，它調用了createcontainer("zend_layout")。createcontainer("zend_layout")是在registry中以zend_layout為key，zend_view_helper_placeholder_container類為value的array。

zend_view_helper_placeholder_container實作抽象類zend_view_helper_placeholder_container_abstract，這個抽象類實際上也是一個arrayobject，這個在之前的文章有提到過了，是一個和泛型類一樣的東東。

好了，這裡不跟下去了，回頭到zend_layout的構造函數

_initvarcontainer結束了，下面是調用兩個重要的函數：

$this-&gt;_setmvcenabled(true);

$this-&gt;_initmvc();

mvc大家一定很熟悉，我們來看看這裡是怎麼個mvc的

setmvcenabled沒什麼特别，設定标志位this-&gt;_mvcenabled

_initmvc做了兩件事，_initplugin和_inithelper。

先看initplugin:

擷取pluginclass,這裡的pluginclass就是zend_layout_controller_plugin_layout，可以看到，這裡是作為一個插件的形式放進來的。

接着又擷取了zend_controller_front的執行個體，調用：

$front-&gt;registerplugin(

new pluginclass(pluginclass(this),

99

);

記得前面對zend_controller_front的分析不？裡面有registerplugin的函數，是将插件委托給front的broker來用。有人就會問後面的99是什麼意思？是插件的索引順序，越後面的插件越後執行插件的動作。

下面再看_inithelper：

擷取helperclass，這裡的helperclass就是zend_layout_controller_action_helper_layout

if (!zend_controller_action_helperbroker::hashelper('layout')) {

。。。

zend_controller_action_helperbroker::getstack()-&gt;offsetset(-90, new helperclass(helperclass(this));

}

如果action_helperbroker沒有layout的helper的話

就執行下面的offsetset指令。将-90和zend_layout_controller_action_helper_layout執行個體作為參數傳入。

和plugin同樣的關系，将zend_layout_controller_action_helper_layout執行個體作為value存入到this-&gt;_helpersbypriority和this-&gt;_helpersbynameref去了

前面的-90是權重，也是要保證這個helper是最後調用（看最後一行是krsort排序）

好了，layout的構造函數就這樣分析結束了。