Version one of our product was, as far as versions one go, functional. It was written some time ago and we had just signed a contract with a big company to add some major features to it. With that in mind, we thought it would be a good opportunity to build a better base.

That being said, we didn’t want to refactor all the code base. The first version was built on top of the Zend Framework 2 and it was using Doctrine as an ORM. The ugly part was that it lacked structure everywhere else : big custom javascript files to do AJAX calls and form validation, custom security module for page and resource access, and so on. You know it, we know it, this is a plan for unmaintainable code. And, to be real honest, it was.

This is why we started off the version 2 with maintainable code in our head. We wanted more stable libraries instead of custom code, and something to replace all the custom javascript code. For that last part, we settled on AngularJS.

The hardest part about that last choice is that there wasn’t any guide on using AngularJS with ZF2. So we built one! Read on for the fun steps.

Getting started

This article is going to show you how to build a simple architecture using ZF2, with Doctrine2 as an ORM and ZfcUser as a user management library. To top it off, we are going to use AngularJS to add some dynamism to the frontend.

Zend Skeleton

We started off by installing the ZF2 Skeleton Application provided by Zend.

Doctrine2 with skeleton

Then we used this Using doctrine 2 in Zend Framework 2 guide to use Doctrine2 in our project.


We also needed a user management library, that’s when we stumbled upon SamUser which we are now using in our projects. This module uses ZfcUser, BjyAuthorize and Doctrine to manage users in the application.


Then comes the tricky part. Since we chose to use AngularJS in our project, we needed a way to include it in our frontend. That’s why we decided to use the routing in ZF2, and to fetch the data using a Restful API built from our ZF2 routes.


This is the configuration for one of our modules. The TaxesController shows the template whereas the RestController answer API requests by sending the needed data.

Each module has its own file for a controller and another file for the service definition (which has the $resource object).


This is our file structure in the public/js folder. We use Grunt to build all the javascript files into one that we uglify in production.

We interact with the data by simply fetching it, showing it on the screen and updating only the needed part using a $watch on the objects.


We are pretty satisfied with the chosen architecture. It’s dynamic for the user and easier for us to maintain (up to this point).

We have open sourced the skeleton so feel free to use it or even contribute.