In his past few posts Paul Jones has been looking at dependency injection versus service locators. In this new post he continues on the topic comparing three methods for working with objects - factories, registries and service locators.

In last week’s episode of this unexpected series, I said, “Go ahead and use Service Locator, but make sure each Locator contains only one type of object. This condition of restraint will keep a single locator from becoming a menace.” [...] The “only one type of object” constraint generated some discussion regarding factories and registries. [...] The differences between factories, registries, and containers (both service locators and dependency injection containers) can be subtle and hard to grasp at first. Here’s how I keep them straight.

He breaks them down with a simple definition for each related to how the object is created and its intended purpose. He also includes an example of a service locator he's created and a snippet of example code showing it in use.

Again, I must stress: Service locators can easily get out of control. If you can avoid using a service locator, you should.

Mathias Verraes has a new post today with a response to an email he received about some comments on a recent Elephant in the Room podcast about Value Object usage. The question asks about usage of Value Objects, specifically when it comes to things like country information.

There’s nothing intrinsically wrong with modeling countries as entities and storing them in the database. But in most cases, that overcomplicating things. Countries don’t change often. When a country’s name changes, it is in fact, for all practical purposes, a new country. If a country one day does not exist anymore, you can’t simply change all addresses, because possibly the country was split into two countries. Whenever you have this kind of friction, there’s usually some missing concept screaming to be discovered.

He talks some about the concepts around the "country" data and some of the functional concerns around it (duplicate checking, validation of existence, etc). He takes the concept and breaks it out into two different concepts - the actual Value Object of a single country and an "AvailableCountries" set (and "AvailableCountryRepository").

Russell Walker has a post on his site sharing some suggestions about effectively dealing with global data in your PHP applications.

Almost every web application needs to handle global data. There are certain things that just have to be available throughout the entire code base, such as database connections, configuration settings, and error handling routines. As a PHP developer, you may have heard the mantra 'globals are evil', but this naturally begs the question 'what should I use instead of global variables?'

He includes four different options (five including the actual use of global variables):

• Static classes
• Singleton
• Registry
• Dependency injection

For each of the options he includes summaries of both the advantages and disadvantages as well as some sample code showing their use. Ultimately, he points out that it's up to the developer of the application which option fits best.

New on PHPMaster.com today there's a tutorial showing you how to access the Windows registry with PHP with the help of the win32std extension.

The Windows Registry is simply a hierarchically structured database in which the Windows operating system and other applications store important configuration information. All sorts of data is stored in the registry: user profiles, file-type associations, hardware information, serial numbers, and more. With functions available from the win32std extension, your Windows-based PHP applications can access the registry too. The win32std extension can be downloaded as a pre-compiled library from downloads.php.net/pierre/. Simply drop it into your PHP’s ext folder, update your php.ini file, and restart Apache if necessary.

The article talks a bit about the general layout of the registry, the main five keys and the encouragement of making a sandbox registry to perform your operations on rather than taking a chance. He shows how to use the extension's functions to read from the registry and write back out to a certain key. Their example application performs a check on the registry to see if a USB dongle is attached to the system based on a key being set and the device ID.

Stuart Herbert has a new post today showing how to get the well-established PEAR package management system working on Windows 7 so you can easily call "pear install" on whatever your needs might be.

So that I don’t forget how to do this next time around. Worked for me, your mileage may vary. First step is to get a working install of PHP. [...] At this point, you should be able to open up a Command Prompt, and type ‘php -v’, and see the response ‘PHP v5.4.latest …’ appear as expected. Now for PEAR itself.

He gives step-by-step instructions on how to get PEAR up and running - downloading and configuring it with the correct Windows-based paths and using the PEAR_ENV.reg file to update your registry.

Court Ewing has written up a post looking at an alternative to a commonly used bad design pattern - the global registry dependency - a method that uses a singleton to control access to a class-wide instance of an object.

This gives you flexibility when configuring and setting your adapter, and it allows you to instantiate a new service without having to explicitly set commonly used dependencies, but you are ultimately just replacing one hardcoded object call with another. This means you are still limited in your ability to unit test the class properly, and you will have a difficult time debugging if you ever need to find out exactly when and where your database adapter was configured.

In his simple solution uses static methods to assign the database adapter when the bootstrap process is started instead of when the object is created. This adapter is assigned to an abstract class, so it's created even outside the class instantiations. There's one caveat to doing things this way, though - depending on the needs, you might have to have more than one abstract class and things could get tricky.

Brandon Savage takes another look at a popular design pattern - the registry pattern - and how he's changed his thinking on its use a bit on how (or if) it should be used in your applications.

Last July, I wrote about the registry pattern and some of its advantages. These advantages include the ability to access objects across different areas of your application, and the storage of objects for later retrieval. [...] For me, over the last few months, I’ve discovered two reasons why I advise against the Registry Pattern: first and foremost, it discourages unit testing, and secondly, it discourages good design.

He goes on to elaborate on why these to things could be so detrimental to your code including the problems it can cause in tests being a point of failure and that it can make you application sloppy by giving you an unpoliced "bucket" to drop things in without any context to where they fit in the site.

So what's his suggestion to replace this bit of functionality and make things both easy to test and simpler to keep structured? Dependency injection.

Continuing on from the first part of the series, Marc Plotz forges ahead in his development of a PHP MVC (Model/View/Controller) framework. This new article gives a more complete overview of how the entire framework is structured.

Unlike the previous part, I am not simply giving you the part of the framework that we discuss, but a much more complete version. You will need a MySQL database to run it on, and you will have to setup the connection in application/db.ini.php. My example should guide you. You should not have to do much else than create the database and connect to it.

You can grab the source here and follow along with the tutorial as it steps through bootstrapping and a registry that replaces a "super global" handling method that could cause trouble.

Brandon Savage has posted a quick look at using one of the more popular design patterns - Registry - to handle object storage and retrieval.

One of the biggest challenges in OOP programming with PHP is the ability to pass around objects and let other objects use them. This challenge can be solved with careful design, however. Here we will discuss the registry pattern, not a member of the GoF's original patterns but still an important pattern nonetheless.

He looks at a few different ways to solve a few different problems - first, sharing a database resource between multiple objects, then making sure that you have a connection no matter where its called from and finally - what the registry is used for - sharing multiple database connections between multiple objects. He uses static methods in an abstract class to handle the set/get of the correct object.

There's also a bit of discussion about the registry pattern versus dependency injection and which is better for most instances.

Justin has posted a few cool things that you can do by combining PHP with someof the Windows functionality PHP has access to (either via direct function calls or through the COM object).

Many PHP examples out there are designed for a linux/unix operating system. I am going to give some examples of some interesting functionality that only works with php running in a windows environment (IIS or apache).

Hist list includes little things like ejecting the CD-ROM and sending things to the printer out to working with the registry and listing the current system processes.