Though in the past they enjoyed both popularity and a certain amount of prestige, without a doubt Singletons have progressively become one of the most evil and despicable villains in object-oriented design. Singletons earned their bad reputation for a reason: bringing them to life requires the programmer to deal at least with a static method. This is simply an elegant masquerade for creating a global access point (which in most cases is mutable as well) throughout an entire application. And we all know that global, mutable access is unquestionably a bad thing that must be avoided at all costs.

In this first part (of two) of the series they introduce the Singleton pattern and show how, via an example of using a database adapter interface to work with a MySQL database, in a tightly coupled example. In the second part of the series, they'll show how to break these apart using dependency injection.

So few days ago I needed to insert Oracle XMLtype with Zend Framework. I used oracle adapter to wrote it in Zend Framework. I was looking for and I found on Chris Jones Blog.

His table has a column defined as an XMLType, a special data type specifically for working with XML datasets directly in the database. His adapter includes a bit of sample XML and the code needed to bind the data as a CLOB and, using the writeTemporary function.

Within the Design Patterns world, there are four main categories: Architectural, Structural, Creational, and Behavioral. Architectural patterns describe the system as a whole, Structural patterns describe the relationships between objects, Creational handle creating objects, and finally Behavioral describe the communication patterns between objects. Each of the categories is worth discussion on its own, but in this case we'll stick to the Structural patterns of Adapter, Facade, and Decorator.

He describes each of the patterns (no code in this one, just descriptions) and for each mentions some of the tools that the Zend Framework has to offer that match up. For example, the Adapter pattern is used in quite a few places in the framework including in the Zend_Db component for the connection types to different databases.

As ugly as this technique is, it works. The problem is it requires an extreme amount of intelligence or an extreme amount of simplicity in the query in order for an automated system like Doctrine to be usable. The biggest caveat with this technique is good goddamned luck paging your query if it doesn't have an ORDER BY. And sometimes queries that are complex enough break the modified Zend_Db code. There exists an easier MSSQL paging technique. Using features first available in SQL Server 2005, with only 1 subquery you can mimic MySQL's LIMIT clause with ease.

He includes the query that will make it happen (the SQL for it) and then the implementation as an adapter you can use to get it to cooperate in your Doctrine queries.

Design patterns are optimized, reusable solutions to the programming problems that we encounter every day. A design pattern is not a class or a library that we can simply plug into our system; it's much more than that. It is a template that has to be implemented in the correct situation. It's not language-specific either. A good design pattern should be implementable in most - if not all - languages, depending on the capabilities of the language.

They introduce a few of the more widely used patterns including the strategy pattern, adapter pattern, factory methods, decorator and singleton patterns. Each comes with a bit of code showing how it would work and a "where would I use this?" section with a better example.

What if you want to use multiple methods? OpenID? Facebook Connect? Saml? or one of the other dozen+ solutions that you might use.. What to do? One thing to keep in mind, Auth happens really early in the bootstrapping process so things like SQL may not be available yet unless you specifically loaded it in the config.. Then you need to load the proper auth module and call it as needed..

He includes a code example of how it would work - extending the Solar_Auth_Adapter to create a single "multi-adapter" with a switch to evaluate and load/use the correct authentication method. It uses the Solar_Config object to set the Auth Adapter when it's loaded so you can even use multiples in the same page load if you need it.

I've been using Doctrine a lot in my own work, and recently found myself itching to have tighter integration between Zend and Doctrine when it comes to user logins. Luckily, Zend provides a very simple interface with regards to Zend_Auth. This way, it's easy to decouple your persistence layer (in my case Doctrine) from the authentication layer.

He also recommends checking out Palo Verede's look at the same topic. You can watch the screencast here and grab the code for it here.

Solar makes heavy use of Adapter based classes, Solar_Auth is one of these. This makes adding additional methods pretty easy and allows you to borrow from other Frameworks without having to Hack in a third party auth setup, You can use the basics provided by Solar.

He includes a code example showing how to extend the Solar_Auth_Adapter component to create an OpenID adapter you can use as a part of your authentication process. His Solar component encourages code reuse too by using the Zend Framework native OpenID implementation as its authetication functionality.

In 2008, Paul M. Jones announced the release of an SQL adapter that allows Solar users to connect to master/slave database installations. My first reaction was: Great! This will inspire other FOSS developers to create similar components. And guess what, it did. I wrote my own ReplicationAdapter. It's not great, but it's flexible enough to support the most commonly used replication scenarios:

He gives examples of how it can be used for single-master replication, multi-master replication and how the adapter can be used to create a distributed caching system for database connections. A brief Zend Framework-based example is also included.

From time to time I write some little scripts for my own needs or just to test out new stuff. And I realised, that I blog about it way too little. So here I start with my latest addition: Zend_Auth_Adapter_Twitter. [...] I came up with a Zend_Auth Adapter for Twitter. The integration was pretty easy, but the code is very basic and rough. Nevertheless, it does the job and alongside the Openid Adapter I can offer a federated login for many people already.

You can grab the code and an example of it in action from their SVN server (as well as this library) or just check out the live demo.