Just a quick update on a little project I've been working on over the past few months. Idiorm is “a lightweight nearly-zero-configuration object-relational mapper and fluent query builder for PHP5,” and is released under a BSD license.
The starting point for Idiorm was the topic of my talk at BarCampBrighton last year: “Minimalism in Web Development”, the idea that for many purposes, simpler solutions are often preferable to complex ones.
Idiorm lets you start using an ORM in your application with almost no effort. No XML files, model classes, database introspection or code generation is required: You just need to tell the ORM how to connect to your database, and away you go.
The fluent interface allows you to build most basic queries without writing any SQL, and gets out of the way when you need to do something more complex (both raw WHERE clauses and complete raw queries are supported). Once you have one or more instances of the ORM class (representing the rows in your database tables) you can access the data in them directly as properties of the objects (using PHP's magic __get and __set methods internally), modify and save them, as well as delete them. For full documentation and lots of code samples, see the README file.
Obviously, such a simple project (the whole ORM class is only about 600 lines of code) would probably never be used in a huge, complex PHP application. The main drawback to using a generic ORM class instead of domain-specific model classes is that you can't attach your own behaviour to the models. So the (extremely sensible) idea of placing most of your business logic in your models (Skinny Controller, Fat Model) isn't possible with Idiorm as-is.
I have three answers to this problem. The first is that many applications simply don't need any business logic more complex than basic CRUD operations, for which Idiorm is perfect. Secondly, one clear use case for Idiorm is to clean up legacy applications which are littered with raw SQL statements, usually passed directly into some custom-written “database abstraction” class or set of functions. Here, the application is already a mess, and in the absence of a complete rewrite, integrating Idiorm can only make things better. Finally, there's no reason why you couldn't build a full model layer as a lightweight wrapper on top of Idiorm. This would probably take the form of a factory object which returns instances of the correct model class, using Idiorm to populate them with data. I have a rough-and-ready implementation of this idea on my laptop which I may release at some point, but it's easy enough to build yourself. If you're using PHP 5.3 (and so have access to late static binding), you could even code up a pretty nice implementation of the active record pattern around Idiorm.
Update: I have now released Paris, which is an Active Record implementation built on top of Idiorm.
So to summarise, Idiorm isn't really intended to replace something like Doctrine or Propel (or ActiveRecord, or Django's ORM, or SQLAlchemy, etc). It's designed to be a quick and easy solution to database abstraction in small-to-medium sized applications. And let's face it - most of us are building small-to-medium sized applications. We're building bicycles, not space shuttles. If Doctrine is a rocket engine, Idiorm is a bottom bracket. But if all you want to do is get to the corner shop, a bicycle is a much quicker way to travel.
Finally, if you think you'd find Idiorm useful, please let me know. Fork the project, make suggestions using GitHub's Issues system or just leave a comment on this post.