APE is the rebranded (and apparently aggressively refactored) AdaptableStorage Zope product by Shane Hathaway. APE uses many of the patterns outlined in Martin Fowler's "Patterns of Enterprise Application Architecture" that deal with mapping objects to relational databases. I don't have the time to go into it now, but I want to point to this outline about the system.
A nice thing about APE, like the Enterprise Objects Framework (EOF), is that storage is heavily abstracted away from the persistent object itself. This actually allows for different storage mechanisms, such as the file system (making human-editable files) or other database systems such as MetaKit.
A recent comment on my earlier "Quick Look at WebObjects" post asked for a comparison of SQLObject and the EOF. I hope to get to this soon. I haven't actually used SQLObject, but it looks to be a useful lightweight system. It uses metaclasses to facilitate the mapping. But it really seems to be a simple (but I imagine very usable) solution. APE, Modeling, EOF are all full scale persistence systems. They all do things like faulting/ghosting (delayed fetching of objects), and should allow for conflict resolution, verification, serializing, etc. They move this code away from the object itself, which is the right thing to do in my opinion. Just like I flinch whenever I see HTML in a print
statement (HTML and programming code DO NOT MIX), I flinch whenever I see words like column
, table
, etc in a business object.
Roundup is a good example of a system written with database abstraction in mind. It can store its data in DBM, MetaKit, Berkeley DB, SQLite, MySQL, etc. And you can (fairly) easily move from one storage system to another (basically, one just has to go through an export/import step, by my understanding). Advantages? I can tweak and work with my schema for my customized Roundup application and not worry about the database underneath. When performance becomes an issue, I can move on to a system like MetaKit or SQLite and have zero impact on my application.
Sometimes, it goes the other way around - needing to design an application around existing database data. Sometimes, that's the tricky one.