Xml Interfaces Reloaded

Thursday, April 17, 2003

"Jesse Ezell has a post where he criticizes my recent entry on Tight Coupling vs. Loose Coupling. He seems to have drawn the same conclusions I did about Interfaces vs. Abstract classes when it comes to versioning APIs then asks why using an API based on abstract classes that represent an RSS item isn't better than passing around IXPathNavigable objects. He correctly points out that an API based on objects is easier to code against than one based on passing around XML. However, the goal of passing around XML instead of objects is flexibility and not necessarily an easier programming model."
[Dare's Diary] While I agree that flexibility is important and that the easiest way to give this flexibility is to just pass the raw data around. However, if you ask me that is not a solution but a cop out. Instead of solving any problems yourself, you force every developer who interfaces with your code to do so. Proving an extensible object model allows you to solve many issues while allowing developers to add extensions as they are needed.

Case and point, anyone who works with the SoapReflectors, SoapExtensions, etc. that are part of the framework will quickly realize why a rich object model is a vastly superior solution. The fact remains that WS-* space is a heck of a lot more complex and evolving a heck of a lot faster than the RSS space, yet the object model provided by MS remains easy to use and extensions to the base functionality are not as beholden to the application (the .NET Framework in this case) as Dare would have you believe. How many posts have you seen from developers saying, "man this ws-extensions toolkit is really cool, but I wish Microsoft just gave us a XPath navigator instance instead"?

No Comments