Here’s an old topic with a new twist. Back in the old days we used to worry about using Engine Specific sql code on order to be able to port an application to another database engine than the one on which it was developed. The way you did this was to use (as much as possible) only ANSI syntax in your SQL so that it would work with ANSI compliant engines. For the most part this worked really well. As ANSI specifications matured the power of SQL matured as well.
Today the options are even broader. Do you establish interfaces allowing you to persist your data to different kinds of storage, or do you write your application to work with a specific persistence framework? For example, you could write your persistence code to work directly with Entity Framework, NHibernate, Hibernate or JDBC. This makes writing your application quicker because you don’t have to maintain an interface; especially if you don’t plan to implement any different persistence than the one you are implementing now.
Is it better to add an interface in later when you find you have another storage engine to implement, or should you start out with an interface in your initial development? If you follow the SOLID principle of Open/Closed this is easier to apply using interfaces, and perhaps that is a better answer than the potential of a new storage engine. Using an interface you can extend current capabilities without breaking earlier contracts.
So, where do we stand in the modern world? Is this something we need to care about? If we choose to ignore the potential how risky is the result? Does your implementation depend on the type of application your are creating; in house, package, Software as a Service, departmental, Enterprise? Share your thoughts in comments online or by email to btaylor@sswug.org.
Cheers,
Ben