Should our code be DBMS-agnostic?
This became a topic of discussion in the U2 forum recently and I thought I’d post some brief comments here about how I approach this topic with client code that interfaces to the MV DBMS.
I work on this kind of stuff every single day and I find myself on both sides of the “database agnostic” fence.
On one hand I try to write my client-side code so that it’s independent of any specific DBMS provider. Not only do I write applications to be MV DBMS agnostic using mv.NET, but I have created a connectivity library to keep it product-independent. It has UO.NET, QMClient, mv.NET, MVSP, and even a SSH command-line interface built-in, so that I can connect to any MV environment without changing a line of UI or middle-tier data access code. I can deploy some of my code to any MV site, and if pressed, the code will work with “other”, should the worst situation occur.
On another hand, sites that are investing in modern technology are usually not likely to migrate. If they’re getting what they want from their existing platform, there’s no motivation to migrate to “just another database”. For an end-user site, a client UI that’s independent of the MV DBMS has little value over one where the MV platform hooks are hardcoded.
On yet another hand (gotta be versatile here) for application and tool providers, platform independence has a Lot of value because it broadens the audience for their offering. Unfortunately for many vendors in our space, products are often hardcoded for one platform and porting to another is a significant chore.
As far as coding for complete back-end independence, I have never seen a site migrate to a different back-end platform without completely replacing their front-end too. In the modern world it’s the front-end that sells the app. A site that moves to a completely new back-end has no interest in old tools that plugged into their old system. By definition, they’re replacing it, they want out.
So sure, I keep my tiers agnostic of one another because the code is elegant, but sometimes I sacrifice elegance to just get the job done. That kind of coding takes time=money and sometimes we just don’t have the luxury. It’s up to each developer as to where they draw the line: Use tight integration between tiers because they will probably always be intertwined? Separate tiers to avoid some other developer shaking their head at poor technique? Completely abstract tiers for real concerns? Or vary the approach with each project, and sometimes with each module within a project?
There are no absolutes.
What do you think?