What the hell use is that!?


  • Discourse touched me in a no-no place

    What idiot came up with ye olde XmlSerializer? It can't serialize references? Seriously? Here's how you do it, guys. You serialize each object flat and give each one a GUID. When one object's property references another, you stick the GUID in the property - you don't nest the entire fucking object again. Job. Fucking. Done.

    Then again, XML Serialization seems to be a favorite of arsebandit "Enterprise" developers who only want to throw around some simple structs, not complete application states.

     

    .Net serialization is such a clusterfuck. XML doesn't support sanity and makes unreasonable demands about every class on the planet needing a parameterless constructor. SOAP doesn't support generics. Binary is... Well, it's fucking binary. But it works with literally no effort at all. Now if only I could be reasonably confident of its ability to weather codechanges.



  • That's general property of the whole .Net standard library. It does not make easy things easy (because it lacks sane defaults and obvious helpers in many places) and it stops half way to making complicated things possible (it has the flexibility, but does not have all the necessary bits).



  • If it makes you feel any better, Java's one is pretty similar in the problems you mention.



  • This is one reason I'm writing my own serializer.  That, and I want binary formatting in Silverlight.



  • @hoodaticus said:

    This is one reason I'm writing my own serializer.

    And apparently, you also hate yourself!

    @hoodaticus said:

    ...Silverlight.

    Oh, no, just masochistic. Sorry, I misunderstood.



  • @Weng said:

    What idiot came up with ye olde XmlSerializer? It can't serialize references? Seriously? Here's how you do it, guys. You serialize each object flat and give each one a GUID. When one object's property references another, you stick the GUID in the property - you don't nest the entire fucking object again. Job. Fucking. Done.

    Then again, XML Serialization seems to be a favorite of arsebandit "Enterprise" developers who only want to throw around some simple structs, not complete application states.

     

    .Net serialization is such a clusterfuck. XML doesn't support sanity and makes unreasonable demands about every class on the planet needing a parameterless constructor. SOAP doesn't support generics. Binary is... Well, it's fucking binary. But it works with literally no effort at all. Now if only I could be reasonably confident of its ability to weather codechanges.

     

    This is easy to get around, if you design your services properly.  And by that, I mean use a different object model for your schema than you do internally; that way, you can have all your references internally, but map them to an external schema with integers or guids or whatever you want to use for your identifiers.  This has the added advantage of not requiring you to break your schema whenever your internal data processing needs change, and you should probably be doing it anyhow.



  • "Plain Old Xml" should generally NOT use references, which is why the XmlSerializer is written the way it is. If you have a "key/value" relationship, then the model should represent this and things will work just fine.

     That being said, there are plenty of reasons why you want to serialize object graphs other then "POXml", and there are other serializers available that prefectly well support reference graphs, including loops (e.g. parent references a collection of children, and each child references the parent)

     All of these are available out of the box with .NETand I have never had any problems related to serialization that were not cleanly solved by using the correct design paradigms and tools.

     Most of the replies here seem like "I have a hammer in my toolbox so I am going to use that to cut bolts, rather than looking in the toolbox to find my bolt cutter".



  • My main dislike with XmlSerializer is that it for each new type you give it, it spends about a second of cpu time writing, and compiling, and loading a temporary class to perform the serialization. Sure, it speeds up benchmarks where you might serialize a million objects, but for the typical case, it means serializing just one object takes about one second. It seems all the .net serializers are like that.

    I suppose the delay is alright for a long running web service where it happens only once. But it can be annoying if you use serialization in a desktop app, not realizing ahead of time how much it's going to add to load time.

    In my case, I ran into the problem using the PersistentDictionary class that comes with the ESENT Managed Interface. Seeing how slow it was, and wrongly blaming ESENT, I set out to write my own persistent dictionary, and didn't realize the serializer was to blame until I was pretty much done.



  • I recall running into the code emit wall a while back, but there is an easy, and documented workaround IIRC...  I'm too lazy to look it up now, but there was an overload which essentially used the cached temporary assembly instead of builing a new one everytime the ctor was called (which also caused memory leak issues because each new assembly would be loaded into memory).

    EDIT: reading fail on my part...  I didn't notice you said for each new type.  Yes, thats the case, but that's not that bad of a hit IMO.  How many different object types are you using?



  • @dtfinch said:

    My main dislike with XmlSerializer is that it for each new type you give it, it spends about a second of cpu time writing, and compiling, and loading a temporary class to perform the serialization. Sure, it speeds up benchmarks where you might serialize a million objects, but for the typical case, it means serializing just one object takes about one second. It seems all the .net serializers are like that.

     While that is the default configuration, it is definately not a requirement (in fact I very rarely use dynamic generated serializers). If you know the types at build (compile) time, simply create them as part of the build.



  • @TheCPUWizard said:

    While that is the default configuration, it is definately not a requirement (in fact I very rarely use dynamic generated serializers). If you know the types at build (compile) time, simply create them as part of the build.

    This may be a really obvious thing to someone used to C# and VS or whatever, but how would you make that happen? Just interested generally.



  • @boomzilla said:

    @TheCPUWizard said:
    While that is the default configuration, it is definately not a requirement (in fact I very rarely use dynamic generated serializers). If you know the types at build (compile) time, simply create them as part of the build.

    This may be a really obvious thing to someone used to C# and VS or whatever, but how would you make that happen? Just interested generally.

    It is quite difficult...you have to check a box on the build configuration screen if using the IDE, or a switch if using the command line....



  • @boomzilla said:

    @TheCPUWizard said:
    While that is the default configuration, it is definately not a requirement (in fact I very rarely use dynamic generated serializers). If you know the types at build (compile) time, simply create them as part of the build.

    This may be a really obvious thing to someone used to C# and VS or whatever, but how would you make that happen? Just interested generally.

    It is quite difficult...you have to check a box on the build configuration screen if using the IDE, or a switch if using the command line....



  •  @boomzilla said:

    how would you make that happen? Just interested generally.
    It's the default behavior.



  • I'm using sharpdevelop, so I'd have to use the command line option. I did mess with that option a bit but hit some roadblock (can't remember what) and decided I had wasted enough time on it already. I had written the persistent dictionary replacement at home (in monodevelop) on my own time, feeling that I couldn't really justify doing it on paid time, and getting it to work without the delay was using up my time at work. Oddly I didn't notice any delays running it on mono at home.


  • Discourse touched me in a no-no place

    @TheCPUWizard said:

     All of these are available out of the box with .NET
    All I can find is BinaryFormatter (Which works, but the format isn't exactly transparent), SOAPFormatter (which doesn't support generics, likely among other things) and XmlSerializer (which is a total pile of shit).

     

    If you're aware of some ninja-awesome third party serializer, GIMME.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.