Bradley Holt

In my previous post in this series we looked at how Zend Framework applications can be bootstrapped. We saw the configuration file (application/configs/application.ini) and the Bootstrap class (in application/Bootstrap.php) from a demo blogging application, Postr. What happens once your application is bootstrapped and run? That’s where Zend Framework’s routing and Model-View-Controller (MVC) components come in (technically there are a few steps in-between, but we’ll come back to that in a future post).

Model

Your domain objects. There is no Zend_Model since your domain logic is specific to your application. However, there are some best practices that have emerged in the Zend Framework community including Data Mappers (which I’ll talk about later).

See example Models in application/models/

View

The presentation layer. The default implementation uses PHP templates called view scripts. View script files have a default suffix of .phtml. There should be no domain logic in your view scripts. By default, there is one view script per controller action (we’ll see what that means shortly).

See example Views in application/views/

Controller

Connects the Model and the View. Each Controller contains one or more actions. The Controller’s job is to interpret input and pass it to the Model and also to provide Model data to the View.

See example Controllers in application/controllers/

By default, Zend Framework will route requests based on URI segments as follows:

:controller/:action[/:key/:value]

A few example URIs:

• foo/bar (foo controller, bar action)
• foo/bar/baz/shaz (foo controller, bar action, baz=shaz)

It is possible to customize this routing in pretty much any way conceivable but I’d suggest sticking with the default routing until you have a good handle on how it works.

In my next post in this series I plan on taking a slight detour so that we can explore a very useful component, Zend_Layout.