October 24, 2012

For The Love of Tesla, Encapsulate Third-Party Code!

I started working on a project earlier this year for a client. We were tasked with upgrading an ASP.NET 1.1 /SQL Server 2000 application to ASP.NET 4.0/SQL Server 2008 in the initial phase. Everything was going well until I looked into upgrading the OR/M that was used by the application.

It turns out that the OR/M had been completely rewritten since the old version, so upgrading to the latest version of the OR/M would break the application. That didn't matter so much, however, because the old version of the OR/M was already breaking the application! Additionally, the old version of the OR/M was no longer supported by the developer (we couldn't even buy paid support for it if we wanted to), so we'd have no help if we tried to stick with the old version. We realized very quickly that we had no other options... regardless of whether we upgraded to the new version of the OR/M or replaced it with a different OR/M entirely, we were going to have to rewrite a significant chunk of the application's codebase.

It took over 80 man-hours to replace the old OR/M with a new one. It didn't have to be this way.

Switching OR/Ms was such an onerous task because the original developer had failed to encapsulate his use of the OR/M within the application. As a result, there were hundreds if not thousands of references to the OR/M's artifacts dispersed throughout the DAL project, BLL project, and ASP.NET web application. Had the original developer encapsulated the OR/M, switching to the new version (or another OR/M) would have saved us countless hours, because we'd only be making changes in the DAL project; the rest of the solution would have remained unchanged.

If the moral of this story isn't crystal clear, it's that you should - no, you must - encapsulate your data access code!

But let's step back and see if we can refactor the moral of the story. The OR/M issue I just told you about is a specific example of a more general problem: using ANY bare third-party APIs throughout your application will exponentially increase switching costs, which will make it difficult if not impossible for you to convince your manager to let you switch from jQuery to mooTools, or EF to NHibernate, in 6 months. The situation becomes even worse if, let's say, you decide you want to switch from PHP to Ruby on the server-side but you have mingled PHP into your HTML markup.

The fact is that while third-party libraries and frameworks make it extremely easy to get an application up and running quickly, simply dropping them into your codebase creates a tight coupling between your application code and the library's code, and you should know by now that's bad design.

So, whenever and wherever you use a third-party API, make sure you wrap it with your own API so that switching or upgrading the third-party API doesn't cripple your application or cost an arm and a leg in development time.

Post a Comment