Interfaces, Abstractions, Separation of Concerns, and Everything Else I DIDN'T Do…

Interfaces, Abstractions, Separation of Concerns, and Everything Else I DIDN'T Do...

This is a post about what NOT to do.  We have a web service that returns us information about customers.  Not much thought was ever put into how to use this service intelligently, the one way we were doing it worked, and we went about our business.  So I've just described how to guarantee that a web service becomes a single point of failure in your application.

Let's say we have application A that has a critical dependency on application B.  Application B has a dependency on a web service that's maintained somewhere else.  Today for various reasons, the web service was ordered to be shut down.  There's a replicated database we can use that contains pretty much the same data as the web service with a slight delay in the replication.  So why not just switch over?  Ugh...

First of all, there's a ton of code that goes something like this:

string url = ConfigurationManager.AppSettings["ws_url"];
WebServiceProxy proxy = new WebServiceProxy(url);
string xml = proxy.GetStuff();
SomeParser parser = new SomeParser();
ConcreteClass obj = parser.Parse(xml);
//ConcreteClass is defined from the web service
//all remaining code now utilizes the concrete class

What's the problem?

Well, that code is spread out in various manners in hundreds of spots throughout the application.  So let's say I want to get the data from the replicated database, I now need to change every reference to point to this new data.  But everything is bound to this stupid class defined from web service proxy, so that makes it suck more. 

Now What

Well I tried to fix it tonight and after bout 2 hours of updating code, i was not even close so I through in the towel. What should I have done and what needs to happen?

Whatever data that is pulled back from the web service needs to be nicely tucked away behind an interface. All client code needs to be updated so that it has no clue where it's data comes from, all it knows is that interface, and that's it. 

Construction of the system that will go retrieve the data from whereever, needs to happen in exactly one spot.  This is a good time to introduce dependency injection into the mix, that's for sure.

This dependency has bugged me for awhile but because of all of the code changes I've avoided doing anything, but now our apps are dead in the water, so that may have moved the necessary changes up the priority stream, so to speak.

Print | posted on Wednesday, August 29, 2007 8:43 PM