ZF1与ZF2的对比

http://blog.hock.in/2012/09/06/zf2-for-zf1-users-part-1/

Modules

ZF1

Modules in Zend Framework 1 aren’t really modular at all. ZF1 modules are really a method of grouping descrete areas of code together, without them being inherently reusable. It’s impossible to grab a ZF1 module that someone else has used, and quickly and easily drop it into your project.

ZF2

Zend Framework 2′s modules really are modular. You can drop in someone else’s module, and with a simple line added to your application config file, you can be up and running in seconds. One of the key objectives when writing ZF2 was that it should make modular code-reuse as simple and easy as possible. I think this has been achieved with distinction. Once the ecosystem is established and mature, you should be able to easily add common functionality to your ZF2 project by simply picking and choosing the modules you need from the repository.

To quote a famous telephone manufacturer, need user registration and login functionality? There’s a module for that.

The Zend Framework Commons team are a group of community contributors who are comitted to releasing high quality modules with the Zf-Commons namespace. ZfcUser is a user registration and login module written and maintained by them. Because it’s Zf-Commons, it has an implied level of quality and maintenance. So, if you want to add user login and registration, it’s simply a case of adding the ZfcUser dependency to your composer.json file:

"require": {
    "zf-commons/zfc-user": "dev-master"

Now, when you do a php composer.phar update, composer will pull in ZfcUser (and it’s dependency ZfcBase) into your “vendor” library directory. Including the module is just a simple case of adding ZfcUser to your list of installed modules in application.config.php. The module needs a little configuration (create the database tables it uses and tell it which database connection to use), but because modules have their own routes, controllers and view scripts, once it’s enabled you have a fully working user registration and authentication system available at the /user entry point in minutes.

Bootstrapping

ZF1

Bootstrapping resources in ZF1 has evolved to be a combination of directives in the application.ini, and underscore prefixed functions in a module’s Bootstrap.php. Generally, things that can be instantiated with minimal or no configuration can be added to the application.ini, whereas more complex resources that may need dependencies or similar are handled in the Bootstrap.php. Each module can (and should) have it’s Bootstrap.php. As an example, you can bootstrap the Zend_Translate object using an _initTranslate method in the application Bootstrap.php like this:

protected function _initTranslate()
{
    $translate = new Zend_Translate('array',
            APPLICATION_PATH.'/lang/en_EN.php', 'en_EN');
    Zend_Registry::set('Zend_Translate', $translate);
}

This instantiates a new Zend_Translate object using the array adapter, and adds the English translations from the en_EN.php array file. It then puts it into the registry, having a ‘Zend_Translate’ key in the registry automatically enables the translate view helpers.

You could also use the application.ini (or Bootstrap.php) to include front controller plugins. Front controller plugins allow you to hook into any part of the dispatch process and run custom code so that you can perform actions on every request. A great example of code that is typically performed on every request is authentication. ZF1 expects the developer to write his own authentication methods using Zend_Auth, and usually this was handled in a FC plugin:

class Central_Plugin_AuthPlugin extends Zend_Controller_Plugin_Abstract
{
     public function
        dispatchLoopStartup(Zend_Controller_Request_Abstract $request)
     {
        // if not logged in, redirect to the login page
        // create an instance of Zend_Auth
        $auth = Zend_Auth::getInstance();
        // if not logged in
        if (!$auth->hasIdentity())
        {
            // set the new controller name to be the login controller
            $request->setControllerName('login')
            // set dispached to be false so the dispatch loop starts again
            ->setDispatched(false);
        }
     }
}

Which is loaded in application.ini by:

resources.frontController.plugins[] = "Plugin_AuthPlugin"

ZF2

There is no application level bootrapping in Zend Framework 2, each module is responsible for bootstrapping it’s own resources in it’s Module.php. This is done using a combination of the onBootstrap method of the module class, and the Event Manager. We’ll go into the Event Manager in more detail in Part 2. Realistically, most bootstrapping is no longer needed; it’s been replaced by entries in the Service Manager (covered in Part 2), and event hooks (also covered in Part 2!), but as an example, here is how you can perform module level bootstrapping by using the onBootrap method of Module.php:

public function onBootstrap(\Zend\Mvc\Event $e)
{
    $myService = $e->getApplication()->getServiceLocator()->get('my-service');
    $myService->doBootrappingCode();
}