Zend Framework Structure

  • 1
  • April 11, 2011
Douglas Radburn

Douglas Radburn

Head of Technical

Powered by ZEND FRAMEWORKOn large open source builds, we use Zend Framework. The Zend Framework is a Model View Controller (MVC) Framework. The idea of this is to separate out the application logic from the user interface, allowing independent development, and maintenance of each step.

As part of this, we start all sites with a basic folder structure based around incorporating Zend; kind of like a framework around a framework.

We’ve worked on several projects in a particular way, but for our most recent project (a redevelopment of competwition.com) we started from scratch. We got a brand new shiny version of the framework (version 1.11), and sat down to properly plan out how we wanted the new framework to be built, and allow for it to expand in the future.

One of the main issues we came up with was how to structure the site around having a frontend and a backend (admin system), which may in some ways share a lot of data with the front end. For example; if you’re running a site with many products, your frontend will have the ability to query the database for the product information and display it, and so will your backend.

Models ‘model’ the data in an application – they do the database interaction too. This means that their logic should probably be shared between the two.

Our sites usually have a different admin area layout to help our users interact with the data they’re managing. This means that the layout and view ‘logic’ can be separate for the frontend and backend. In some systems, it might be best to keep these in the same place – if you’re allowing in-line editing for example.

The actual operation/controller ‘logic’ is also separate between the frontend and backend of the system. This is due to the different roles the two sides of the system allow for – the frontend will be mainly for viewing products (in our e-commerce example), whereas the backend will have the ability to add, edit, delete and view the products. Logically, it makes sense to keep these interaction sets separate, but as mentioned previously, the model logic can be shared between them.

At the end of the brainstorming session we came up with the following structure: