JCooney.NET

Joseph Cooney's Weblog

NAVIGATION - SEARCH

If I don't understand it, or it doesn't work the way I expect it to then it is broken

Often I see somebody complaining that some API, class or library is broken. Windows forms list views are broken because they allow you to put anything into them. Webforms are broken because they are not as rich as winforms. Winforms are broken because they are not the same as webforms. Value types are broken, Xml Serialization is broken, enums are broken, regex is broken. Broken Broken Broken. It is amazing that any software gets written at all considering all these half baked frameworks, ill-conceived APIs and shoddy implementations. Are all these things really that bad? This is the real world: software has bugs, and there are a finite amount of resources that can be brought to bear designing and developing any piece of it. However I think in most cases the most broken thing is the developer's understanding of the thing which they claim is skrewy. It seems that some people truly believe that if they don't understand it, or if it doesn't work the way they think it should then it is crap. Some people will even discount things without reading the documentation (shame on me, I've done this one too).

Often it seems that the key piece of information that is missing is understanding. In .NET I occasionally find some part of the framework and just can't figure out why it is the way it is. Xml Serialization is a good example - at first I just couldn't understand why the XML serializer seemed so limited. I knew it was possible to write something that allowed "full fidelity" type serialization to XML, so why didn't the XML serializer do this? It was only when I realized that the intention of the XML serializer was to serialize types to XML where .NET may not be running on the other end (ala web services) that I finally understood why it was the way it was *. Understanding the why of certain libraries (either their intended function, or some restriction they are required to operate under) can help a great deal when using them.

I'm not sure why people do this - maybe they have been burnt before and have learned to expect sub-standard things, maybe it is a form of ego protection, but I think developers do themselves a great dis-service when they write something off as broken after a relatively brief exposure to it. They rob themselves of a chance at better understanding by "flipping the bozo bit" and moving on. Using something while understanding the zen of it is a lot easier than constantly wrestling with a class or API that you just don't properly understand.

* Note: It seems that Microsoft is aiming at improving the interoperable xml serialization capabilities in .NET for Indigo, so maybe Xml Serialization (as it currently stands) is a little broken compared to what is to come.

Comments (3) -

Frans Bouma
Frans Bouma

Your reasoning is broken, the XmlSerializer IS broken.



you want to know how? Implement the undocumented (but required!) interface IXmlSerializable in a class. The XmlSerializer will always think it is a dataset, no matter what.



The XmlSerializer can't work with Event handlers (which is weird as they will never end up with any data in the class) nor with cyclic references (myCustomer.Orders[i]==myOrder;myOrder.Customer = myCustomer). This is also bad as it is essential in a lot of class graphs.



Because teh XmlSerializer is ALWAYS used in a webservice, this can be really annoying. You may say that it isn't broken, but it is. I can't implement IXmlSerializable on my classes to fix this, although my code is completely able to serialize/deserialize itself to Xml, including cyclic references (even loops).



Thats what I call broken: it might work in some situations, but it doesn't in all situations. If that's the case, you have to limit the scope of the object, however it is ALWAYS used in webservices.

Enjoy Every Sandwich
Enjoy Every Sandwich

Take Outs for 31 March 2004

JosephCooney
JosephCooney

As far as IXmlSerializable goes, in framework 1.0 and 1.1 it bears the following description:



This type supports the .NET Framework infrastructure and is not intended to be used directly from your code.



msdn.microsoft.com/.../...rializableClassTopic.asp">msdn.microsoft.com/.../...rializableClassTopic.asp



It seems that in whidbey this interface is going to be fully supported (see: weblogs.asp.net/.../34313.aspx">weblogs.asp.net/.../34313.aspx) of course Frans is no doubt aware of this already because he commented in this post.



As far as things like cyclic references and interfaces go - what DO these things translate to in an XML Schema? Dare seems to think that the CLR type system is a subset of XML, so maybe the object -> XML serialization will become less broken in the future. www.25hoursaday.com/.../PermaLink.aspx">www.25hoursaday.com/.../PermaLink.aspx

Comments are closed