More reasons why CodeProject is bad Thursday, May 08 2008
I've never really liked CodeProject in the first place, and now there's a funny spat going on between a couple of people on there. First you have Nine Reasons to Not Use Serialization. First off, the author of this article is making very broad arguments against "serialization", most of which are from knowing too little or by thinking that you are limited by XML serialization. I'm going to go ahead and comment on each of the 9 points:
1. It forces you to design your classes in a certain way
Basically the author is saying that you need public classes and public default constructors. For the XmlSerializer and SoapFormatter classes, he is correct. However, for the BinaryFormatter class that is not true. This isn't necessarily all that bad, and in the cases where it is bad, you just wouldn't use automatic serialization anyway.
2. It is not future-proof for small changes
3. It is not future-proof for large changes
4. It is not future-proof for massive changes
These are really all the same point and I think he was really trying to squeeze out 9, since "7 reasons..." doesn't sound as good. Anyway, the author is definitely correct, automatic serialization can be a tough cookie when versioning code. The small and large changes can be overcome using the ISerializable interface, as can massive changes, however if you are drastically changing your object model after these objects have already been serialized, you have a larger issue there. Automatic serialization has times it should be used and times when it shouldn't be used. It should be used when you're saving simple system settings, etc and not when saving business objects or drastically important bits of data (we all know when to use a database). And actually, if you have a relatively simple object model that can be serialized, using XML (not SOAP) serialization correctly can yield the exact same results as writing the XML by "hand", and those results are massive-proof since they're readable by any language easily.
5. It is not secure
Whether this even matters is of little concern, since no matter how you persist an object to disk, you have security issues. No matter where you persist to or how you do the persistence, the internals of your classes are exposed (that's the nature of persistence).
6. It is inefficient
Correct, and anyone who thinks that they should persist all data using a simple serialization scheme has no right to be developing applications. I use an RSS Reader that is not a .NET application and persists everything to XML, and it's eating up about 3MB on my disk (cached items, feed lists, etc). No matter how they chose to serialize (access database, MSDE, XML, CSV, etc) there would be roughly 3MB used on my disk anyway (since the smallest part of the XML is the XML tags themselves in this case).
7. It is a black box
This part is very true, however I don't think the author should admit to not knowing how serialization works. My first rule of writing: if you don't know what you're talking about, don't talk about it. Aside from that, Joel Spolsky wrote an excellent article called The Law of Leaky Abstractions that helps explain this a lot, and explains that in order to use abstractions, you really should familiarize yourself with what is being abstracted. It is very easy to figure out what is happening in the various serialization techniques: open your favorite decompiler (Reflector or Anakrino, etc) and find the Serialize and Deserialize methods.
8. It is slow
I have no arguments about this, other than "well of course it's slower".
9. It is weird
I can't argue with this other than to say that everything is weird if you don't understand it. Executing a SqlCommand and returns a SqlDataReader is technically weird if you don't know what's going on. However, once you do understand it and know how to work with it, it makes a lot more sense.
That said, there were a number of comments either for or against this article. One person, however, stood out with some initial rude comments that caused even more rude comments. The author of the original rude comment decided to post an article of his own to counter the original article (and comments) called Dispelling Crazy Rumors about .NET Serialization.
In this article the author mimicks the 9 point format, which is good, however I think the plethora of spelling mistakes throughout the article (including "Displelling in the title") take away pretty much all credibility from the author. Because I feel like it, I'll go point by point again on this guy.
1. Jumping Points
This is by far the worst rebuttal point, and for three reasons:
1. The article is titled "9 reasons...", obviously there will be some point jumping.
2. This rebuttal in fact jumps points.
3. Don't you see how much a numbered point-jumping system worked when I said I was going to have three reasons?
2. Serialization is in .NET is a general frameworkwith two broad implementations. SDK development is always geared towards commn functionality accross broad ranges.
Correct, however there are three broad implementations (XML, Soap, Binary).
3. Although the concept of serialization is addressed in .NET, it is not a unique facet of .NET. The pattern of persisting state is as ancient as boolean gate feedback...
This point is definitely correct, and something I mentioned above.
4. Name one thing in this crazy IT world we live in that is future proof!
This only addresses the "Massive Change" point, not the "Small" or "Large" ones. He is correct, however, that bringing up technology/language change isn't necessarily that big of a deal. It reminds me of the time I went to a .NET class and this one guy was so excited about XML Serialization, but then you could see the disappointment when he found out his Recordset.Save code to save to XML wouldn't be natively readable by .NET XML Serialization. Change-proofing your design and whether you use automatic serialization don't necessarily go hand-in-hand.
5. How is BinarySerialization using a CryptoStream not secure?
Correct, you can definitely serialize your output, however I still think the original point is moot.
6. New Flash, the public visibility problem the author highlighted in XML Serialization is BY DESIGN.
More rudeness, plus way too many smiley faces throughout the text. I hate when people use smileys for no reason.
7. Seriously whatever architect who would come up with a design where 100,000 objects needed to save state using binary or xml format serialization probably needs their head checked.
I peep what he's knocking here, and he's dead on. This goes back to my statement about there is a place for automatic serialization and a place for another persistence mechanism.
8. Do some research on Whidbey if you really really really want to have serialization of private variables.
I really have no idea.
9. This is in response to some of the comments I got back. It seems some people out there feel that I did not address the issue of real world situations where 100,000 object need to be serialized so here is my response:
Unfortunately he didn't organize the title fo the responses very well, so I keep having to quote way more than I want to. This goes back to his #7, about how you wouldn't serialize thousands and thousands of objects directly to disk, but should use a database instead (or as he said, SRUD - I'm pretty sure he means CRUD).
Unfortunately neither article was written very well. The first was written obviously without much knowledge on the subject, and the second was written in too much haste and clearly without a spell checker. That just helps me realize more that it's hardly worth checking out that site on a regular basis.
1. It forces you to design your classes in a certain way
Basically the author is saying that you need public classes and public default constructors. For the XmlSerializer and SoapFormatter classes, he is correct. However, for the BinaryFormatter class that is not true. This isn't necessarily all that bad, and in the cases where it is bad, you just wouldn't use automatic serialization anyway.
2. It is not future-proof for small changes
3. It is not future-proof for large changes
4. It is not future-proof for massive changes
These are really all the same point and I think he was really trying to squeeze out 9, since "7 reasons..." doesn't sound as good. Anyway, the author is definitely correct, automatic serialization can be a tough cookie when versioning code. The small and large changes can be overcome using the ISerializable interface, as can massive changes, however if you are drastically changing your object model after these objects have already been serialized, you have a larger issue there. Automatic serialization has times it should be used and times when it shouldn't be used. It should be used when you're saving simple system settings, etc and not when saving business objects or drastically important bits of data (we all know when to use a database). And actually, if you have a relatively simple object model that can be serialized, using XML (not SOAP) serialization correctly can yield the exact same results as writing the XML by "hand", and those results are massive-proof since they're readable by any language easily.
5. It is not secure
Whether this even matters is of little concern, since no matter how you persist an object to disk, you have security issues. No matter where you persist to or how you do the persistence, the internals of your classes are exposed (that's the nature of persistence).
6. It is inefficient
Correct, and anyone who thinks that they should persist all data using a simple serialization scheme has no right to be developing applications. I use an RSS Reader that is not a .NET application and persists everything to XML, and it's eating up about 3MB on my disk (cached items, feed lists, etc). No matter how they chose to serialize (access database, MSDE, XML, CSV, etc) there would be roughly 3MB used on my disk anyway (since the smallest part of the XML is the XML tags themselves in this case).
7. It is a black box
This part is very true, however I don't think the author should admit to not knowing how serialization works. My first rule of writing: if you don't know what you're talking about, don't talk about it. Aside from that, Joel Spolsky wrote an excellent article called The Law of Leaky Abstractions that helps explain this a lot, and explains that in order to use abstractions, you really should familiarize yourself with what is being abstracted. It is very easy to figure out what is happening in the various serialization techniques: open your favorite decompiler (Reflector or Anakrino, etc) and find the Serialize and Deserialize methods.
8. It is slow
I have no arguments about this, other than "well of course it's slower".
9. It is weird
I can't argue with this other than to say that everything is weird if you don't understand it. Executing a SqlCommand and returns a SqlDataReader is technically weird if you don't know what's going on. However, once you do understand it and know how to work with it, it makes a lot more sense.
That said, there were a number of comments either for or against this article. One person, however, stood out with some initial rude comments that caused even more rude comments. The author of the original rude comment decided to post an article of his own to counter the original article (and comments) called Dispelling Crazy Rumors about .NET Serialization.
In this article the author mimicks the 9 point format, which is good, however I think the plethora of spelling mistakes throughout the article (including "Displelling in the title") take away pretty much all credibility from the author. Because I feel like it, I'll go point by point again on this guy.
1. Jumping Points
This is by far the worst rebuttal point, and for three reasons:
1. The article is titled "9 reasons...", obviously there will be some point jumping.
2. This rebuttal in fact jumps points.
3. Don't you see how much a numbered point-jumping system worked when I said I was going to have three reasons?
2. Serialization is in .NET is a general frameworkwith two broad implementations. SDK development is always geared towards commn functionality accross broad ranges.
Correct, however there are three broad implementations (XML, Soap, Binary).
3. Although the concept of serialization is addressed in .NET, it is not a unique facet of .NET. The pattern of persisting state is as ancient as boolean gate feedback...
This point is definitely correct, and something I mentioned above.
4. Name one thing in this crazy IT world we live in that is future proof!
This only addresses the "Massive Change" point, not the "Small" or "Large" ones. He is correct, however, that bringing up technology/language change isn't necessarily that big of a deal. It reminds me of the time I went to a .NET class and this one guy was so excited about XML Serialization, but then you could see the disappointment when he found out his Recordset.Save code to save to XML wouldn't be natively readable by .NET XML Serialization. Change-proofing your design and whether you use automatic serialization don't necessarily go hand-in-hand.
5. How is BinarySerialization using a CryptoStream not secure?
Correct, you can definitely serialize your output, however I still think the original point is moot.
6. New Flash, the public visibility problem the author highlighted in XML Serialization is BY DESIGN.
More rudeness, plus way too many smiley faces throughout the text. I hate when people use smileys for no reason.
7. Seriously whatever architect who would come up with a design where 100,000 objects needed to save state using binary or xml format serialization probably needs their head checked.
I peep what he's knocking here, and he's dead on. This goes back to my statement about there is a place for automatic serialization and a place for another persistence mechanism.
8. Do some research on Whidbey if you really really really want to have serialization of private variables.
I really have no idea.
9. This is in response to some of the comments I got back. It seems some people out there feel that I did not address the issue of real world situations where 100,000 object need to be serialized so here is my response:
Unfortunately he didn't organize the title fo the responses very well, so I keep having to quote way more than I want to. This goes back to his #7, about how you wouldn't serialize thousands and thousands of objects directly to disk, but should use a database instead (or as he said, SRUD - I'm pretty sure he means CRUD).
Unfortunately neither article was written very well. The first was written obviously without much knowledge on the subject, and the second was written in too much haste and clearly without a spell checker. That just helps me realize more that it's hardly worth checking out that site on a regular basis.
