I recently had a problem with a ZF2 based website where users were reporting seeing the error page displayed, but I couldn't reproduce in testing. To find this problem I decided to log every exception to a file so I could then go back and work out what was happening. In a standard ZF2 application, the easiest way to do this is to add a listener to the 'dispatch.error' event and log using ZendLog.

He uses an event listener to attach a service that contains a "logException" method. This method uses the ZendLog component to write out the error message to a local log file including a backtrace of where the issue occurred.

Both ZF2 and Symfony 2 offer the same behavior: if I'm in a controller, and I want to use a service, I have to get it from the container with $this->get('my_service'). As such, the controller is not using DI, this is the service locator pattern. Controllers become more difficult to tests because of that, and they depend on the container now. I wonder why both frameworks didn't go further: why not treat controllers like services and use dependency injection on them. In other words: if a controller needs a service "A", then it should get it in the constructor, or through setter/property injection.

The comments talk some about the "controller from the DI container" idea, some other ways around the problem and some clarification as to what the frameworks are actually doing related to the container injection.

I previously talked about the terms I use for objects in the model layer and now it's time to put some code on those bones. Note that,as always, all code here is example code and not production-ready.

He includes sample classes related to his "books" examples - a "book" entity (with title, author, id and ISBN), a mapper object to load/save/delete the entity and a service object that provides an interface for the entity to the rest of the application.

I currently use a very simple set of core objects within my model layer: entities, mappers and service objects. [...] I dislike the phrase "service object" as the word "service" means so many things to so many people. I haven't heard a better phrase yet that everyone understands though.

He defines each of the types of objects to help make the separation clearer. Here they are in brief:

• Entities are objects that represent something in my business logic.
• Mappers know how to save and load an entity from the data store.
• Service objects provide the API that the rest of the application uses.

Some of the comments on the post relate his choices to use in Zend Framework v2-based applications, noting that there are some base components you can extend to create these kinds of objects.

If we are working within a Symfony2 application or a PHP application that uses the Symfony's Dependency injection container component you can easily integrate this simple script in the service container. I will show you the way that I use to do it.

His sample code uses the Guzzle HTTP library and some configuration options from a YAML file to create a new service hooked into the Twitter API with his credentials. He then imports it via his services configuration and shows an example of it in action - getting the latest contents of his timeline.

One common misconception about silex and microframeworks in general is that they are only suited for small, simple apps, APIs and prototyping. Of course, those use cases are the main selling point, but they are by no means the limit of what is possible.

He shares some code that's the common "first steps" for someone using the framework, but points out a better way - moving your controller handling out into separate files instead. With a built-in feature of Silex, you can specify the "path" to another class file that will handle the request and return the response back to the main app. He also suggests extracting even more of the functionality out into "service" classes to handle the processing, cleaning up the controllers even more. He finishes off the post with a brief comparison between Silex and a full Symfony2 application, noting that Silex is a bit more "free form" when it comes to structure where Symfony2 apps are pretty well defined and have their conventions.

Recently I've picked up the Silex framework for a project I'm building. It uses a service container for managing dependencies in your application [Pimple], which is great for defining (not instantiating) objects and their default behaviors in a single location, rather than sprinkled throughout your code in a multitude of places. [...] Using Pimple you can define several hundreds of objects, and then easily instantiate them using the container object.

He goes through some example code showing how to use Pimple to create and manage the dependencies by creating several instances of DateTime objects. He shows how this can then be "upgraded" to a service container by defining something like a PDO object (database connection) inside it. He also mentions some of the benefits that come with its use - easy resource swapping, simpler mocking for testing and allows the use of the Inversion of Control pattern.

There's currently a pull request in the queue for Silex that adds a cookbook entry for using controller classes, but I wanted to take it a step further and have my controllers as services, much like what's possible with the full symfony framework (See Richard Miller's post for further reading).

He includes some example code showing the creation of the Silex application with a service definition, the custom "ControllerResolver" to override the default and a simple controller class ("PostController") that just returns a JSON response. You can find the full example code for it on github.

Zend Framework 2 uses a ServiceManager component (in short, SM) to easily apply inversion of control. I notice there are good resources about the background of service managers (I recommend this blog post from Evan or this post from Reese Wilson) but many people still have problems to tune the SM to their needs. In this post I will try to explain the reason why the framework uses multiple service managers and how you can use these.

He talks about the different service managers that are available in the framework, why they're used, how they relate to the service locator and how you can define/fetch your own services in them. He includes some basic configuration code and compares the behavior of the root service manager to the others (application services, controllers, view helpers, etc).

Most of us are familiar with seeing URLs like bit.ly or t.co on our Twitter or Facebook feeds. These are examples of shortened URLs, which are a short alias or pointer to a longer page link. [...] In this article you'll learn how to create a fully functional URL shortener for your website that will work whether you use a front controller/framework or not. If you use a front controller, I'll discuss you how to easily integrate this URL shortener without having to dig into the controller's programming.

They help you create a simple database to hold the link relationships, the PHP code to create the randomized hash that represents the link and the code to shorten it. There's also the PHP code to take it the other way and decode the shortened version into the full URL. You can find the full code (ready for checkout) over on the PHPMaster.com Github account.