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.

On his Medium.com site Agustín Houlgrave has posted a tutorial with some suggestions about building PHP console applications correctly.

Googling this topic, I could only find official documentation on Symfony’s Console Component and some tutorials on quick building, but i’d like to write about making a real scalable console application that you could use in an actual production project. I’ll explain the reasons we do each of the things.

I like to write decoupled, reusable and as raw as possible code, so we’ll try to aim on that direction. Also, we’ll take advantage of all of the new features of PHP 7.

He decided on the combination of the Symfony Console Component and the Zend Service Manager to handle the use of the decoupled components. He then gets into the installation of the required packages and the initial code to create the Symfony command. He then sets up the Composer autoloading and the "factory" configuration for the command. From there he includes the code to build out the command runner and gives an example of executing the command and the output.

Alejandro Celaya has a new post to his site showing the Zend Framework users out there how you can reuse factories in Zend/ServiceManager. Factories are heavily utilized by the component to create the objects the service returns. Factories tend to be single-use, however, but Alejandro has shown a way around that.

I like zend-servicemanager because it is explicit, and you are always in control of what's done, without loosing flexibility in the process. Since this container expects you to define factories for every service, you usually end up writing, testing and maintaining a lot of factories that doesn't add value to the application.

That's why it is so important to properly reuse factories when possible, not only because you will have to maintain less classes, but because the ServiceManager will instantiate less objects at runtime when it can reuse a factory.

He then talks about ways you can set up shared factories in your application including the use of an abstract factory class or a concrete factory to return other dependencies required. He also shows how to use the ConfigAbstractFactory that allows for the injection of dependencies based on a configuration (similar to the "wiring" in other dependency injection containers). Finally he shows the use of the ReflectionBasedAbstractFactory that handles the injection in about the same way but instead of basing it on a configuration it uses PHP's own reflection to try to determine the class and autoload it into the current system.

The Master Zend Framework site has a new tutorial posted showing how to generate dependency configurations easily with the help of the ConfigDumper component is a Zend Framework based application.

Want to save time generating dependency configuration files for your Zend ServiceManager dependencies? In today's tutorial, I'll show you how, by using ConfigDumper, available in ServiceManager 3.2.0.

In the previous tutorial, we saw how to use FactoryCreator’s command-line tool, generate-factory-for-class, to quickly and easily create factories for classes.

In this, the follow-up tutorial, we’re going to see how to use generate-deps-for-config-factory, the command-line tool for ConfigDumper, to save time when generating dependency configuration files for use with our classes.

He starts by helping you get the correct version of the ServiceManager installed (3.2.0) and provides an overview of the generate-deps-for-config-factory tool. He moves on to a simple example using one of the included classes (the PingAction) and calls the generator with an example of the results. From there he includes a more complex example using the HomePageAction as its source. He points out that this tool doesn't work for every class and gives an example of a failure around a missing type hint. The post wraps up with a look at the ConfigAbstractFactory and how you can use the configurations that result from using the generation tool.

Gary Hockin has a post to his site today introducing you to the new ConfigAbstractFactory class to work with ZendServiceManager in Zend Framework applications. The library helps make the creation of configuration service factories easier than having to write them in code.

I wanted to introduce the new ConfigAbstractFactory that has been written for ZendServiceManager 3 and got merged to develop today and will be included in the next 3.2.0 release of the ServiceManager.

[...] Laravel has shown us that developer usability is a real thing and that by making things easier for your target audience you gain traction and Good Things Happen. This is why in response to an issue on the Service Manager repository, I’ve written the catchily named Config Abstract Factory. Essentially, it allows you to create service factories from configuration rather than having to write all the code.

He talks about being a fan of the "configuration over magic" approach the Zend Framework has and how, with this new new library, it makes it even easier to directly link configuration files and the objects created based on their contents. He gives a simple example of a UserServiceFactory, first showing the "old" way of handling it then how to shift over to the new abstract handler just defining the same setup in the module configuration.

In a post to his site Alejandro Celaya shows you how to make life easier when using the ZendServiceManager with the help of annotations and a package he's developed to make it all work together.

Everyone who regularly visits my blog knows that I'm a complete fan of the ZendServiceManager component. It is always my choice to deal with dependency injection in any kind of project, more now that v3 has been released, which is faster and has a better public API.

The workflow while working with the ServiceManager is usually the same. You create a factory or abstract factory that creates a service and then you register that service into the ServiceManager itself. Of course you have to optimize your code, and you should try to reuse the same factories whenever possible, and try not to abuse of abstract factories and initializers.

He points out the main problem with using services like this in a larger application, namely that you can end up with a large amount of them, making them difficult to manage (and find problems with). He proposed solution uses this library to minimize the amount of code needed buy injecting dependencies into the service based on "inject" annotations. He includes an example of this functionality in action and includes a few things to keep in mind using the package (like the slower parsing of the annotations some limitations it currently has).

Rob Allen has a quick post to his site showing you how to replace the default Slim dependency injection container (Pimple) with another option.

One feature of Slim 3 is that the DI container is loosely coupled to the core framework. This is done in two ways: The App composes the container instance rather than extending from it and internally, App depends on the container implementing the container-interop interface. [...] Slim 3 ships with Pimple by default, but my preference is for ZendServiceManager, so I decided to integrate ServiceManager into Slim 3.

While he's packaged it up into an installable library, he also walks through the process. He shows how it was implemented via a callback resolver in the ServiceManager. He had a little issue with the "set" functionality but solved it with a few simple "if" checks on the content type before setting it to the container.

Matthew Setter has posted another new tutorial to his Master Zend Framework site today showing you how to access ServiceManager services in controller plugins. Controller plugins are a Zend Framework feature that allows certain events to trigger the plugin code during the lifetime of the controller.

I’ve seen some questions on Google+ and StackOverflow of late, regarding how to get access to the Zend Framework 2 database adapter, along with other ServiceManager-defined services, in a custom controller plugin. This type of setup can come in handy for a number of situations. You may want to access services such as caching, logging or databases and want to provide a simple interface for doing so. People seem really interested in how to do it, but how to get access to services from the ServiceManager doesn’t seem to be as clear as it could be. Gladly, there’s not much involved in actually doing it.

He shows you how to create a plugin for an existing module, creating the two needed classes and adding a new function to configure it. He starts with the plugin factory that can be used to generate an instance of the plugin. Next is the plugin class itself that extends the abstract plugin and controller plugin classes. The required database adapter is injected into it via a constructor injection. Finally, in the Module.php configuration, he creates a "getControllerPluginConfig" method that registers the new plugin and points to its class. A screencast is also provided showing the active development of the code.

On the Master Zend Framework site today Matthew Setter has a new post covering the configuring of the service manager using abstract factories.

One of the best features about Zend Framework 2 is undoubtedly the ServiceManager; because it makes it almost painless to configure and retrieve services in a consistent and predictable manner, anywhere in your application, at any time. [...] But the catch is, there’s quite a bit to learn if you want to use it properly. As well as that, there’s quite a number of ways to use it.

He walks you through some of the pros and cons of the various ways to work with the ServiceManager and where the factories fit in. He takes a bit of time to introduce the concepts behind abstract factories and how to define them in a Zend Framework v2 application. He finishes out the post with a more practical, working example using the interfaces provided to get a "MyUserTable" service.