Alejandro Celaya has a recent post to his site showing you how you can delay constructor execution in your services by making use of the "lazy services" functionality provided by the Zend ServiceManager component.

A couple years ago I wrote a post about how to improve PHP applications performance by using zend-servicemanager lazy services.

In that article I explained how the ServiceManager takes advantage of the proxy design pattern to delay the creation of services, when they are marked as lazy.

That can improve performance if the object is resource consuming, but that is not the only advantage behind proxies.

He starts with a use case for using these "lazy services" based on some changes in an open source library he maintains to add in geolocation support. The library requires a database file when the object is created but on the first run, no file is downloaded yet. He made use of the lazy service loading to only initialize the GeoIp2 library when it is requested and not when the script starts.

On his site Nikola Posa has a tutorial showing how to lazy load services with Zend Manager, a component of the Zend Framework. In this case, the "services" being loaded are in a dependency injection container.

Any more complex application includes a big dependency injection tree of services, some of which can have a more complicated creation logic. If the service is injected as a dependency, but not necessarily used at every execution, you may want to lazily initialize that service until it is really needed.

In those situations, you may be tempted to inject the entire Dependency Injection Container instead, and lazy-load that resource-hungry service. I find that to be an anti-pattern, and I explained my views in a blog post written some time ago.

He offers a better solution in the form of the proxy design pattern, making it possible to decouple the services from the dependency injection container. He provides examples of using this pattern along with the Zend Service Manager functionality to create the factories and the services configuration.

In a post to his site Andreas Möller shares a tool that he uses to get an application up and running quickly, providing a makefile for lazy developers.

Whatever the size of the software project, I believe in, subscribe to, and promote Continuous Integration. Personally, I rely on Travis CI as an automated build system. Regardless of whether an automated build system can be set up and used for a project or not, I prefer to be able to run build steps locally. This prevents stress testing the automated build system and taking away resources from other developers. Also, it gives me more confidence before committing and pushing changes upstream.

[...] For a couple of years now I have been using make, after having been introduced to it when working on a project in 2014. While it has its limitations, it’s short and simple, and most of all, it get’s the job done.

He then talks about the repository he's created to get up and running quickly that creates a simple Makefile to define several make commands and shortcuts for some common tasks. The make it task is the most used, executing all of the other tasks to ensure that all tests pass, the code is well-structured and generates a coverage report to ensure as much of the code is covered by tests as it should be.

The QaFoo.com blog has a new post sharing a helpful hint on refactoring singletons to make them more testable. Singletons and notoriously difficult to test due to how it can potentially return an unexpected version of an object.

So your code base is littered with singletons and using them? Don't worry, you can start refactoring them out of your code base class by class and introduce increased testability at every step. This strategy is very simple to implement and the probability of breaking your code is very low, especially when you are becoming more experienced with this technique.

They give an example of a service class that uses a singleton to get an instance of the Solarium_Client class via a static method call. They show how to refactor this out into a separate method and then use the "lazy initialization" pattern to only use the singleton if the property isn't already defined. This then allows you to use a setter to inject your own client during testing (a mock most likely).

Alejandro Celaya has posted a tutorial to his site showing you how to use ServiceManager 3 to improve performance in your PHP-based application. The ServiceManager is a piece of the Zend Framework.

Performance is an important subject when a project grows. There are some good practices that make projects more maintainable, like dependency injection, however, creating all the objects at the beginning of the request could reduce the application performance. If some of the created objects are not finally used, we have wasted CPU time and memory for no reason.

If we used proxies for every expensive dependency, the previous problem would be solved. We can still inject the dependency, but it will be wrapped by the proxy, which will create the object itself once we need it, or never, if it is not finally used. This is the principle behind lazy services. The ServiceManager makes use of the ocramius/proxy-manager package to create proxies on the fly for all the services configured as lazy.

He talks about the lazy_services functionality the ServiceManager provides and gives an example of it in use defining a database (PDO) connection. He talks some about how it works behind the scenes and how no code change is required to use this new configuration.

In the latest post to his site Marc Morera about the use of "lazy services" with Symfony2. In his examples, he uses a command line application to illustrate his point, but it could apply elsewhere as well.

Since Symfony version 2.4 you can define your controllers and commands as services. This is so useful as long as you need to treat your classes as much decoupled as possible. [...] When we define as lazy a service, this is not instanced when is injected, but only when is accessed. [...] The point here is to define our service intended to work with the model as lazy.

He shows how to implement this kind of "lazy" handling in a command, registering the commands into the services but not creating the instances of them until they're used. He includes some example code showing how this is set up and offers a few tips on the implementation and common issues to think about.

Juozas Kaziukenas has a new post to his Web Species blog about using "lazy evaluation" in PHP - loading the resources you need for execution and evaluation only as you need them, not all up front.

Recently I needed to process a huge array of data and because of PHP's somewhat inefficient variables and especially arrays that was resulting in "out of memory" errors. However, I couldn't use any other tools than PHP so was forced to come up with a solution implementation in it. Here is how I solved it using principles from functional languages.

He gives an example using Haskell to generate a Fibonacci sequence using its built-in lazy evaluation abilities. Unfortunately, PHP doesn't have such a thing built in, so he tries the next best thing - Iterators. He caries the idea over to the database side too, recommending fetch() in a loop over fetchAll() and some effective joins.

On DevShed today there's the start of a new series looking at design patterns in PHP applications. In this first part of the series, they look at lazy and eager loading.

In the case of PHP 5, which is better suited for developing web-based programs, there are two complementary design patterns that can be of great help in building faster and more reliable applications. Of course, as this article’s title suggests, I’m talking about the lazy and eager loading patterns. Despite their rather funny names, they are pretty easy to implement in PHP 5-controlled environments.

To illustrate, they've created a sample class that uses a few class properties and a __toString method to return the values.

From BuildInternet.com today there's a new article from Jason Gilmore looking at PHP frameworks and why they matter to both the developers and the community at large.

Having been a PHP programmer for more than a decade, I’ve come to realize that many of my fellow PHP programmers seem to have a misplaced notion of what being "lazy" is really all about. [...] Suddenly the Web developer was facing so much more than validating user input and connecting to a database [and] the need to be a lazy programmer was more important than ever.

He covers a lot of the basics of frameworks with a focus on the Zend Framework (because of familiarity) - configuration, data validation tools, database connections, display helpers and the inclusion of third-party plugins.

As is mentioned in this new post to Giorgio Sironi's blog, the latest version of Doctrine now includes lazy loading functionality.

Lazy loading is the capability of performing a expensive operation on demand, only when it reveals necessary from a client request. [...] In Doctrine 2 I made some architectural choices implementing the proxy approach, which substitute a subclassing object to every association which is not eager-loaded.

There's two main places you can see these differences - in the one/many to one associations dynamic proxies and collection interface.