ZendFramework2.0 Mvc structure and startup process analysis

First of all, it should be clear that the startup of Zend2.0 and the MVC architecture are completely event-driven. If you do not know much about event drivers, you should first understand what the event drivers of ZF2 are and master the basic EventManager usage. this is the basis for reading this article. See U... "> <LINKhref =" http://www.php100.com//statics/

Summary

The first thing to note is that Zend2.0's startup and MVC architecture are completely event-driven. If you do not know much about event drivers, you should first understand what the event drivers of ZF2 are and master the basic EventManager usage. this is the basis for reading this article. See Using the ZF2 EventManager.

What is the difference between event-driven MVC and traditional MVC? Simply put, it is called by traditional complex stream programs. It becomes a simple binary relationship that registers an event at a time, and then triggers an event at a time. The event is not affected by the code structure and call process, and can be easily decoupled.

The recently introduced ServiceManager is completely unavailable in Zend1. in my understanding, the introduction of ServiceManager is a reflection of the ZF2 development team on Metaprogramming.

The benefits of ServiceManager are:

Visualize the main parts of the Zend architecture to make the structure more organized and easier to understand

Simplify Di configuration and reduce learning costs

It further weakens Bootstrap and makes the entire startup process more concise.

What makes ServiceManager bad is:

Using Di as a layer of encapsulation, you cannot directly control the entire architecture through the configuration file

When user-defined requirements are high, the learning cost is increased because ServiceManager needs to be learned while learning Di.

Now, the chat starts to go to the real Zend2.0 MVC architecture process analysis. here, the ZendSkeletonApplication in May 21 is used as an example:

Part 1: initialize ServiceManager

ZendSkeletonApplication/public/index. php

$ Configuration = include 'config/application. config. php ';

$ ServiceManager = new ServiceManager (new ServiceManagerConfiguration ($ configuration ['service _ manager']);

$ ServiceManager-> setService ('applicationconfiguration', $ configuration );

Read the basic configuration file of the entire application and initialize the ServiceManager required by the Mvc framework.

By default, all classes dependent on this process are written in Zend \ Mvc \ Service \ ServiceManagerConfiguration. ServiceManager is divided into five classes.

Services

Factories factory

AbstractFactories Abstract factory

Aliases alias

Shared Service

The project configuration file application. config. php will re-write the default Zend configuration and load it. for example, if you want to use a custom service, you can write it in the configuration file as follows:

 

　　

Return array (

'Service _ manager' => array (

'Use _ defaults' => true,

'Services' => array (

'Viewmanager' => 'evaengine \ Mvc \ View \ moduleviewmanager ',

),

),

);

 

Part 2: initialization module

ZendSkeletonApplication/public/index. php

$ ServiceManager-> get ('lelemanager')-> loadModules ();

In ServiceManager, ModuleManager is essentially an encapsulation of Zend \ Mvc \ Service \ ModuleManagerFactory. The main tasks include:

Obtain the list of modules to be loaded in the project configuration file.

Traverse modules by configuration and load the configuration files of modules respectively

Merge Module configuration files

In the configuration file, you can use the modules node to control which modules are loaded.

The module load is also Event-driven. it is implemented through the module manager Zend \ ModuleManager in combination with the module event Zend \ ModuleManager \ ModuleEvent, which is triggered in sequence during module loading.

LoadModules. pre before loading all modules

LoadModule. resolve load each module

LoadModule after each module is loaded

LoadModules. post after all modules are loaded

 

Part 3: Start MVC

Finally, in the MVC part, the entire MVC process is accompanied by event-driven. ZF2 defines it as a MVC event, and the execution sequence is as follows:

Bootstrap guide

Route

Dispatch distribution

Render rendering

Finish

For convenience

ZendSkeletonApplication/public/index. php

$ ServiceManager-> get ('application')-> bootstrap ()-> run ()-> send ();

Split into three phases

 

Bootstrap boot phase

$ App = $ serviceManager-> get ('application')-> bootstrap ();

In Zend1, Bootstrap was once the core part of MVC. in ZF2, due to the introduction of event-driven, this part became very simple and clear:

First, all Mvc events are registered in Zend \ MVC \ Application → bootstrap (), MvcEvent is initialized (Request/Response/Router injection), and bootstrap events are triggered.

In this process, the initialization of the View part is relatively complex.

Composition of Zend \ View

In ZF2, the View is also greatly modified, and Layout and Helper are merged into the View. In Zend1, Layout is an independent component. in ZF2, Layout and Template are collectively referred to as ViewModel, and ViewModel is a tree structure, which enables recursive nesting of templates, layout in ZF2 is essentially the ViewModel at the bottom of the tree structure.

ZF2 View consists of the following parts, which are called AlloVince's personal translation. please correct me if it is inappropriate:

View \ View, mainly taking over MVC events

View \ Strategy policyholder: arranges the main container Placeholders of The View, puts the final result of the View into the container, and concatenates the final result into the content that is finally presented to the user.

View \ Resolver decision maker, defines the ing between the template name and the actual path, and decides the final actual file corresponding to the template

View \ Renderer, with the help of the decision maker, converts ViewModel to text output. A renderer must correspond to a decision maker to work.

View \ Model View Model, including all variables that may be used in the View. Tree structure. a View model can contain several submodels.

View \ Helper View assistant to generate HTML tags

In the MVC architecture, Zend \ Mvc \ View \ ViewManager integrates all the above parts to form the entire View.

Zend \ View initialization

Back to the previous section, when the bootstrap event is triggered, the View part made some major preparations, including:

Specify Zend \ MVC \ View \ DefaultRenderingStrategy, which is used to redefine Layout. Register the MvcEvent: EVENT_RENDER event

The injection template listens to Zend \ Mvc \ View \ InjectTemplateListener. The main function is to generate the default View name through the Controller and Action names.

Injection View model listening Zend \ Mvc \ View \ InjectViewModelListener

In fact, we can draw a conclusion that in the bootstrap phase of Zend Mvc, all the preparations for the view are ready, and it does not wait until the route ends or the Controller starts. The intention is that when the route fails, a corresponding view can still be created to display the exception results.

 

MVC startup phase

ZendSkeletonApplication/public/index. php

$ Response = $ app-> run ();

Events in the startup phase include

Route

Dispatch distribution

If an exception occurs, the startup process is terminated early. The Dispatch event may not be triggered and the finish event is directly triggered.

Route start

The most meaningful reconstruction of ZF2 routes is to allow routes to be arranged in a tree structure. priority can be set between routes. For a brief introduction, see Introducing Zend Framework 2.0 Router. Therefore, ZF2 routes can be set under each module, and priority can be increased in some modules. It is suitable for deployment of large-scale applications.

When a route is started, Zend \ Mvc \ RouteListener → onRoute () is triggered, and routes are matched one by one from the tree structure, finally, a route that is best adapted is returned in the form of a Zend \ Mvc \ Router \ RouteMatch object.

Dispatch distribution process

The Dispatch distribution of ZF2 is actually performed twice. one is in Zend \ Mvc \ Application to locate the matched RouteMatch to a specific Controller through parameters, the other is in Zend \ Mvc \ Controller to inject Request/Response and run the corresponding Action at the same time.

The procedure is as follows:

// Dispatch event triggered

Zend \ Mvc \ DispatchListener-> onDispatch ();

// Locate a controller based on the matching routing parameters

$ Controller = $ controllerLoader-> get ($ controllerName );

// Trigger the dispatch of controlller

$ Return = $ controller-> dispatch ($ request, $ response );

Send Final response and end MVC

ZendSkeletonApplication/public/index. php

$ Response-> send ();

After the distribution is complete, if the correct response is obtained from the controller, the operation will continue.

Zend \ Mvc \ Application-> completeRequest ()

The last two of the MVC events will be triggered here.

Render rendering

Finish

// Call the render event of the default MVC rule.

Zend \ Mvc \ View \ DefaultRenderingStrategy-> render ();

The Render event integrates all parts of Zend \ View and finally assembles them into a Zend \ Http \ PhpEnvironment \ Response, which is sent to the user.

This is the complete process of Zend2.0 MVC.

Address: http://avnpc.com/pages/upgrade-ubuntu10-04-to-php5-3-6