The domain layer is separated from the other layers and has no dependencies on Zf_Controller. Adding the domain directory to your include path allows you to load and access Model classes from anywhere within your project.

His code examples show an IndexController extending the Zf_Controller and how a Model can be called from inside it through a getInstance (as long as the model directory is in your path). You can take a look at part one and part two for more information on this alternative component.

Here's the good news: Zf_Controller doesn't have a Router. It uses a very simple mapping to determine the name of the controller and action.

He gives an example of the "non-routing" and how to work with the input variables for the controller instance - defining default values and setting requirements for them (as defined by matching a regular expression).

You can read more about the first part of the series here.

Zend Framework is very flexible and one of its strengths is that it allows developers to implement their own components. The Zend_Controller component, for example, is very powerful. Of course, it's not my intention to replace it, but to offer an alternative that decreases the number of decisions a developer needs to make when developing an application. Meet Zf_Controller.

His controller allows for better backwards compatibility, better performance, removes the need for circular references and drops the need for Singleton classes. He includes an example of the updated directory structure the class would use, a bootstrap comparing with/without the new class and the rest of the scripts needed for a sample application (view, layout, error controller, etc).

Zend_Controller_Front gets an instance of Zend_Controller_Router_Rewrite, routes the request, iterates through all the provided routes and matches its definitions to the current request URI. The problem with this is that the more routes you add, the more time the router will take to find a positive match.

Federico includes a few benchmarking stats to back this up ranging from four routes up to forty. His solution is to place the routes in different files and set the location with a Zend_Config_Ini object. This makes the controller only load the ones that are needed instead of pulling all forty into memory to have to parse through.

Videos that have already been posted to the section include setup videos part one and two as well as a look at working with the Zend_Controller and Zend_View components.

Zend Framework 0.6.0 release comes with improvements in Zend_Controller area (new Zend_Controller_Request, Zend_Controller_Response classes, dispatch process improvements), which looks very promising. Dispatching process now better described and its parts (Zend_Controller_Router and Zend_Controller_Dispatcher) are replaceable.

He also includes a diagram of how it's all laid out and a brief description of how each of these new pieces works.