About a month and a half ago, I wrote an entry titled Component Relational Mapping?. It covered a new direction I had taken in my ongoing quest to cut down on the amount of SQL I had to maintain for an application. This new direction entailed dropping the object-relational mapping dream which can be awfully difficult to obtain. The dream was replaced with a series of more explicit components that interfaced to the RDBMS to help me build and validate forms, apply that data to a "Table Gateway", and have that generate the appropriate DML statement.
For the most part, it has worked rather well. We now have much more stable administration screens, and schema modifications require a lot less manual labor in terms of having to update INSERT and UPDATE statements, the Python code that wraps them, and the forms for adding/modifying them.
This week I've been applying the same principles to a simple application that stores its data in LDAP. Considering the vague requirements and starting from scratch (not to mention that it's been a long time since I've dealt with LDAP), the application has come along at a pretty quick place by applying pretty much the same design patterns mentioned in that earlier post. Now, much of the application can be built by merely describing the data. There's no end to how much I love that concept.
Plus, this time I was wise enough to put in some Unit Tests for the core communication components. Unfortunately, I did not do that last time around.