The Windows Azure APIs came a long way since they were originally released. On a few occasions, the new versions weren’t very backwards compatible. During those moments, people who use the APIs directly in their code had a tough decision to make.
Do we rewrite the code or stay with older APIs?
That’s a tough place to be! This is why my message is so important, don’t be a fool, wrap your tool!
Creating adapters or facades for external dependencies is practice that should be a natural reflex.
There are times when it can be difficult to fully isolate dependencies, because its not always as simple as it sounds. When this situation comes up, design patterns can be used to guide and inspire our work. Keeping the bits of code that you do not control isolated will save your company a lot of money. Every time a new update comes out, which by the way is almost every 3 to 4 months, your company is going to ask itself the same question.
Do we take the risk of updating?
Updating Windows Azure APIs shouldn’t produce these kinds of questions. In the end, updates should be beneficial. Because if they weren’t, there wouldn’t be much of reason for a newer version to exist in the first place.
Waiting for the next version, is essentially delaying the inevitable moment where APIs get deprecated. When a new updated version comes a long, the update process can be simplified by having to modify a wrapper instead of your entire codebase.
Another options is to create components hidden behind interfaces, which can be swapped out without affecting the interface consumers.
Working with Windows Azure Queue Storage Service can be repetitive, so I created the QueueWorker. This component can be hidden behind an interface. If the Windows Azure team breaks the API used to communicate with the Queue Storage Service, the modifications to my code will be concentrated within this component and not throughout my application.
Is your codebase safe from breaking changes from the Windows Azure APIs?
References
- Direct links to feature guides, client library reference, and REST API reference documentation.
- API References for Windows Azure
- Adapter – Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces
- Understanding and Implementing the Adapter Pattern in C# and C++
- Facade – Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.
- Component-based Development – An individual software component is a software package, a Web service, or a module that encapsulates a set of related functions (or data).
Alexandre Brisebois ☁ 