Friday, August 15, 2008

Persistent Ignorance. Is that another acronym

Gone are the days that we couple our data access code within our business layers/logics., the days of manually writing SQL scripts is over and stored procedures are becoming un-popular in Object Oriented Programming because the paradigmn is shifting from data cetricness to object focuseness. We write code in the modern day using modern tools and languages like C#, Java, Smalltalk, C++ etc These platforms or languages follow common design structure which is termed as object orientation. With the fact that we use OOP, we always want to use the OOP semantics in our coding culture, analysis, and software designing. In other to separate data from OOP,we have seenthe birth of many ORM frameworks (Object Relational Mapping) and code generations and yet there are still many on born frameworks comming into play very soon.Soon we will feel the quantum leep from data centeredness to object orientation.As part of the shift in paradigmn, we saw the birth of AOP (Aspect Oriented Programming) yet many are coming.

Our focus today will be about Persistent Framework and how the industry have tried to make them persistent ignorance. For those who dont understand, persistent ignorance is the ability of our domain model to be ignorant of our persistent framework. The following code is not persistent ignorant :

public class Foo : IPersistable;

The class Foo above, is a domain entity class, but it is forced to implement IPersistable because its a requirement by the underlying persistent framework. If you want to change persistent farmeowork then the problem comes, you will change so many code to make your class compliant to the new persistent farmework.

Most Persistent Frameworks are not Persistent Ignorant, how do we plan for cross ORM frameworks, when we decorate our entities with attributes, we must implement IBigBoss, we are forced to make our POCO or POJO abstract, we use mapping xml file that are embedded into our assemblies (The XML approach is the father of couping because It goes with our transparent POCO'S as embedded resource. This does not allow for Refactoring with the range of refactoring tools we have today).

As we proceed,with the chaotic nature of our industry, we realize there is no silver bullet, even though we longed and waited for the miracles to happen, some of us have realized that we cannot wait forever, something need to be done, that is where Open Source framework comes into play, and different types of AOP (Aspect Oriented Programming) framework's filled the whole programming community.

Recently, i am searching for a Persistent Ignorant ORM Framework, and i realiazed that there is none, even if there is any, the framework will be descriptive [Meaning that you must obey the do's and dont's].

There have been several long debates going on in the Object Persistent Industry, but there havent been a silver bullet, and there wont be any. Relational is not Object period. So we still need a way to tell the Persistent Engine how the transformation will be done. If Microsoft claims to give us such functionality without the use of Visual Studio to hide the intricacies of the mapping, we are ready to sing the "oh happy day".

Most of us (The developers, Analyst, Architects etc) are the root causes to what is happening to software engineering today, we always want a rocket scince, something that cannot be done without plumbing, but have we forgotten that even the JVM's OR CLR's of today is hiding somethings away from us if not, why cant we all start programming in Bytecode or IL or ILasm. Even OOP have its own semantic's which we must follow, if we must use the language. So i wonder why we cannot live by the semantics of ORM mapping and yet we ask too much of the framework.