Joey Beninghove makes an excellent point in his most recent article. He describes creating an additional service layer (which he refers to as the anti-corruption layer) for shielding your application from services with bad APIs. I use this technique constantly, although I generally call it a defensive design layer. It particularly comes in handy when I have to work with WSDL-generated web service proxies. I don’t want that junk leaking through my application, so I generally create my own facade that works the way I expect it to, and translate to the underlying web service as necessary. (This also means I can mock up the web services more easily during development and testing.)

In fact, one of the projects I’m working on right now has a defensive design layer to shield against the API of Microsoft Reporting Services. Kudos to Microsoft for exposing the functionality via a web service, but I really wish they would have spent some more time making the interface logical. Take the “device info” junk that you have to pass to the ReportExecutionService in order to render a report. Extensibility is great, but you’re telling me they couldn’t come up with a better solution than passing an XML string as one of the parameters of the method call? Sheesh.

Relying on a defensive design layer in your application can also protect your application from changes in the underlying service itself. In extreme cases, it can even help you to replace a third-party component with your own custom-rolled one.