Dead Object Frameworks

I just came up with a new categorisation of application frameworks, which funnily enough places rails and most of the hibernate based java approaches in the same category: dead object framework.

What do I mean with that? Well being all eagerly object orientated our domain is nicely modeled in classes, whatever language we choose. In theory (that is what we have to tell ourselves) these are enforcing all kinds of contracts on our business objects. However taking a close look how all those frameworks work, we quickly realise, that the instances of these class are highly transient and live for about one request. If we look even closer we will also realise that people wrote loads of SQL scripts for migrating data, doing reporting and the likes, because doing it in the language of choice “doesn’t perform”. There goes your data integrity…

Contrast this with the way a lively object framework like seaside works. There the actual object instance exists throughout the runtime of the application. If you are changing the same conceptual customer, you are also changing the same instance. This comes very handy when debugging. You can actually inspect (watch) a customer object and see what happens over time and there is a lot less surprises, due to the way objects get externalized and then marshaled back. The lifespan of the object mirros
the lifespan of the conceptual object (yes, I do believe in the value of OOA as a way of thinking about the real world).

If however you are stuck with a relational database, OO is not your friend. At least not as in modelling your business object classes as classes in your programming language. The task of getting data from the database and then throwing it at a browser seems very functional. So you might be better of using functional programming techniques. Meta programming can also be applied successfully. To make it a complete heresy: Delphi is still unbeaten, when it comes to writing applications against relational databases quickly.