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.

Tomas Votruba has written up a new post to his site sharing an update to a project he has to make it easier to enforce various coding standards in your application's codebase. In this update he talks about the Easy Coding Standard project's v4 alpha that includes a "clean" Symfony standard with support for Yaml and Services.

I wrote about news in Easy Coding Standard 3 a while ago. EasyCodingStandard 4 is not released yet (still in alpha), but soon you'll be able to use all the news I'll show you today.

And what are they? Neon to Yaml, semi-static to Services, customizable caching, even simpler skipper, short bin and more.

He breaks the new features down into a list of six updates:

• Configure Caching Directory
• Skip Anything, Anywhere
• Short vendor/bin/ecs is the King
• DI Migration Finished: From Neon to Yaml
• From Semi-Static Checkers to Services as First-Class Citizen
• Good Bye Neon Class Autocomplete Or not?

For each there's a brief snippet showing how to configure it a brief description of what it enforces.

TutsPlus.com has posted the latest tutorial in their "Programming with Yii2" series showing you how to work with cron services to periodically run scripts in your application.

In this Programming With Yii2 series, I'm guiding readers in use of the Yii2 Framework for PHP. In today's tutorial, I'll share with you how to take advantage of Yii's console capacity to run cron jobs.

In the past, I've used wget in my cron jobs—a web accessible URL would run my background tasks. This raised security issues and has some performance problems. While I addressed some ways to mitigate risks in our startup series' episodes on security, I had hoped to transition to console-driven commands. And with Yii2 it's fairly straightforward.

He starts with a brief look at what a "cron" is for those that may not be familiar and how it works on linux-based systems. He then gets into the use of console "cron" commands using the Yii2 framework's own functionality to create a "cron controller" that performs Twitter operations on "frequent", "quarter" and hourly measurements. He shows how to update the crontab file to call the commands instead of making the web requests. He ends this tutorial with an issue to consider regarding different namespaces when using the commands versus web requests.

Vic Cherubini has written up a tutorial on his site showing you how to write functional tests for Symfony services in your application. He provides a practical example of testing a basic Symfony service and the configuration/code to go with it.

The dependency injector is an amazingly simple and flexible addition to Symfony, and one you should be using to properly structure your application. But what happens when you want to write a functional (or integration) test for a service that depends on another service? This article will show you an easy way to test complex services.

He sets up a simple InvoiceGenerator service that takes in a Doctrine entity manager and a "payment processor" instance. He stubs out a simple PaymentProcessor class and shows the configuration needed to set it all up for correct injection. He then gets into the testing of this setup, creating a simple test case that requests the invoice generator from the service container. In this call the services_test definition overrides the default and injects the test payment processor instead of the actual one.

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 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).

Marc Morera has a new post to his site wanting to help you defeat Symfony's expression language and perform the same functionality, just more on the code side (another option).

How beautiful Expression Language definitions are, right? I mean, inserting that complex expressions in a Dependency Injection configuration file is so nice and fast if you need to inject the result of a method in a service (one of the multiple examples we can see). [...] This is not a bad idea, really, but because we are engineers and we should have as much information as possible in order to be able to choose between the best option, always, I will show you another way of defining this piece of code.

He shows how to write some code using the Factory design pattern structure to reproduce a bit more complex piece of expression language. He shows the setup of the services.yml file to define the "managers" and classes/services to be injected. He also notes that this removes the need for the "symfony/expression-language" dependency and makes things more portable in the future.

Igor Wiedler has a recent post to his site about creating stateless services, specifically in the context of using a dependency injection container to manage the objects your application uses.

As more frameworks and libraries, particularly in the PHP world, move towards adopting the Dependency Injection pattern they are all faced with the problem of bootstrapping their application and constructing the object graph. In many cases this is solved by a Dependency Injection Container (DIC). Such a container manages the creation of all the things. The things it manages are services. Or are they?

He notes that, according to some of the principles of domain-driven design, "services" should be stateless - the results of calls to the service shouldn't alter it, it should only depend on the values passed in. He goes on to put this into the context of a DIC and gives an example of the "request service" (and how it violates the DDD principles of statelessness). He talks some about scopes (dependencies) and mutable services. He talks about methods to get around these issues with the "request" instance, ultimately coming to the conclusion that event listeners might be the way to go.

In his recent post Gonzalo Ayuso shows how to use Symfony to work with Windows services on the server.

Sometimes I need to stop/start remote Windows services with PHP. It’s quite easy to do it with net commnand. This command is a tool for administration of Samba and remote CIFS servers. [...] Today we are going to create a PHP wrapper for [net rpc service].

He uses Behat to create a feature (test) file, the code behind the features and a service class that handles the actual work of interacting with the service (with methods to do things like stop, start and list running services). Examples of its use are also included.

On PHPMaster.com today there's a new article from Alejandro Gervasio introducing you to the concept of "services", a layer put on top of your models to make a common API that's easier to reuse.

Don’t let the definition freak you out, as if you’ve been using MVC for a while the chances are you’ve used a service already. Controllers are often called services, as they carry out application logic and additionally are capable of interfacing to several client layers, namely views. Of course in a more demanding environment, plain controllers fail short in handling several clients without the aforementioned duplicating, so that’s why the construction of a standalone layer is more suitable in such cases.

He explains the process behind creating a simple domain model (image here) and shows how the Service layer wraps it up into a simpler interface, leaving the model to handle the business logic. He uses the example of an "EncoderInterface" that's implemented in a "JsonEncoder" and "Serializer" to both provide a "setData" method.