Unlike mappers, though, which are part of the infrastructure, a repository characterizes itself as speaking the model's language, as it's intimately bound to it. And because of its implicit dependency on the mappers, it preserves the persistence ignorance as well, therefore providing a higher level of data abstraction, much closer to the domain objects.

Included in the tutorial is the full code you'll need to create a simple UserInterface class and a User model that extends it. He also makes a UserCollection class to handle working with multiple User objects and a UserMapper to handle the actual data source fetching. Finally, he implements the Repository on top of this base structure showing how it lays on top of everything via the UserMapperInterface instance. At the end some example code showing it in use is also included - making the PDO connection, creating the UserRepository and fetching by a few different data types (email, name and role).

Symfony2 features a brand-new Form component that, to my knowledge, supersedes most existing PHP form libraries in functionality and extensibility (not counting the still lacking, native JavaScript support). [...] The purpose of this post is to demonstrate that the Symfony2 Form component is perfectly suited for this requirement. Symfony2-specific functionality can be unplugged, leaving only the raw core dealing with form processing and abstraction.

The post is broken up into several different sections, each detailing a different aspect of this Forms functionality:

• It's influences from other frameworks
• Key aspects it provides
• Abstraction (reusable code)
• Extensibility
• Compositionality
• Separation of Concerns
• Model Binding
• Dynamic Behavior

Both a high-level architecture and low-level architecture are provided, showing you the internal flow behind the form handling. You can find out more about this component in the Symfony manual or peek into the code on github.

This article describes common pains and symptoms of bad dependency management and common techniques for dealing with project-wide dependencies. [...] For the purpose of this article I am talking about classes using other classes. To manage your softwares dependencies then becomes designing your software architecture such that the depencies are good. The following sections will talk about what's bad, with good being the absense of bad.

In his "problems" section he includes things like "it's easy to do wrong", "it's hard to get rid of", the "low rate of reuse in bad DI" and how bad DI can make for "untestable software". He points to a few packages (including PHP_Depend) that can be used to determine your dependency levels. His methods for "injection" include using the global scope (so bad), using injection in a constructor/setter, making a service locator (registry) and using a full-blown dependency injection container.

All techniques, tricks and gimmicks aside, managing dependencies is more about actual design than abstract design patterns. You yourself are responsible for keeping the number of dependencies as low as possible and designing your system such that access to dependencies is provided in a sane, understandable manner.

Today I needed to get a client application up and running on my local system. This application uses the Geoip PECL package, so I needed to get this up and running. This turned out to be slightly more difficult than just a PECL install, as you're missing some libraries by default, so here is my log of things to do to get it up and running.

He gives the complete list of steps his followed including downloading the source and his way around this "System could not load this extension" issue. The trick was to recompile the source with the correct architecture. By default his extension was built with i386 instead of 64-bit but updating some of the CFLAGS settings (and a few other environment variables) got things compiling correctly.

A plugin architecture allows multiple developers to work on the same application and let yet another person assemble their work later on. It allows the plugin developer to understand just his plugin API without having to understand all the details of the entire application.

He describes a few platforms that already have the concept of plugins including Joomla, Mediawiki and SugarCRM. He explains what a plugin architecture should be and what it shouldn't be. All of this is his first steps towards building a plugin-enabled compiler and virtual machine in PHP.

I'm pretty new to server-side programming, and actually started out with Python/mod-wsgi. From the ground up, mod-wsgi made a lot of sense. The server gets a request, you route the request. It feels like that's where I should start, so that's pretty much what I'm trying to create with PHP (a REST router - for learning purposes, I know frameworks exist). I'm trying to think of a situation where I wouldn't use a REST interface, but I can't seem to think of one (even for simple cases). Would it be safe to say that using REST is a pretty safe bet, most of the time?

There's some good discussion and answers to his question touching on things like Service Oriented Architectures, some implications of having a web service power an entire application (or applications) and a few comments with some personal experience.

A comment about SOA sums it up well:

You learn to write for your platform in the way developers/partners will have to, so you produce a good quality usable API which encourages development and consumption of your platform.

Architectural and design patterns help software architects to break systems in to smaller, more maintainable sections organised by their functionality and usage. [...] There are three major layers in software architecture: presentation, domain and data source. [...] Now that we know what types of layers we can find in software architecture, let's have a look at how we can organize domain logic and data sources layers.

He looks at three patterns that can help organize your domain logic - a transactional script (one file that does one thing), a table module (logic lives in the tables) and his focus, the domain model. He shows (via a graph) how the domain logic approach can cut through some of the effort it could take to improve on the other two. He gives a two suggestions of how to access the data in your domain layer - a Gateway or a Data Mapper. To reinforce the ideas he's presented, he includes some code snippets of a basic domain model for a Store, Customer and Product and uses them in both Gateway and Data Mapper examples.

With the idea of PEAR2 and Pyrus, I had hoped to see a renewal - the advancement of a PEAR architecture for the 21st Century. Instead, and this is just my opinion, PEAR2/Pyrus were a relatively simple iteration on a very old theme. [...] If the PEAR ecosystem has a failing, it is one of staggered evolution. Over time it has picked up additional features tacked on top of a base model.

He breaks up his thoughts on the future of PEAR2/Pyrus distribution into a few different topics - the issues he sees surrounding packaging (like static packaging definitions), suggestions for a dynamic channel aggregation system and overall usage of the PEAR system.

This is a topic I describe at length in my Organizing [Your PHP Projects] talk, but I would like to give the idea a home on my blog for easy reference.

He talks about the typical structure of a PHP application - at least where most start out - being the "include" method. He talks about the progression it usually makes into functions and classes and then, eventually, a jump in concept to the "class" method similar to what several popular frameworks have gone with.

The difference is that no program logic is executed at loading time with a class file. Loading the class file makes it available for use, but the programmer has to instantiate it and then call methods on it for anything else to happen.