What is old is new again....Object Oriented DataStores
There is so much hype about O/R Mappers these days. Visiting Igor Miovanovic's blog got me thinking about persistence frameworks I have written in the past. One in particular was pretty nice. It generated a great deal of code for you using templates that were modeled similarly to ASP.
However, why are we killing ourselves with O/R Mappers. It's silly really. The majority of the data for many data-driven applications are all about storing persistent object data. Why aren't we using tools that handle OO data. Why build a tool that maps object properties to data elements? We are really just creating a whole bunch of needless work for ourselves. If the vast majority of our data structures are about storing object data, then why in the h#$$ are we using relational database technology? If we do need to report off to an RDBMS, why not spend our time building or using a tool that will move data seamlessly from an OO store to a relational store for that purpose?
OO databases have been around for a while. Versant...ObjectStore come to mind. 6-7 years ago, they were quite the rage.....Why aren't they now....I still believe they are ahead of their time. For example, OO has been around for years; however if you are in the microsoft camp and you aren't a hard-core c/c++ programmer, you haven't really been exposed to OO (sorry VB 6 and prior is not OO....).
Now that the vast majority of VB'ers are hitting their stride with OO technologies, they are jumping on mapping data....good when your underlying datastore is SQLServer or Oracle....bad when you have a choice. Instead of fixing the symptom, we should be fixing the problem and the problem has to do with using a relational data-model to map to our OO structures when we should be using a datastore that is more consistent with how we model our software and that is an OO datastore.
IMHO....