SubSonic Forums
All Your Database Are Belong To Us

Serializable classes aren't Serializable

Latest post 05-09-2008 2:10 PM by yitzchok. 3 replies.
  • 05-09-2008 1:23 PM

    Serializable classes aren't Serializable

    It appears that there are a number of classes in the SubSonic API that are/were intended to support Serialization, but that can't be serialized because they lack the correct constructor(s). E.g. SubSonic.TableSchema.Table is decorated with the Serializable attribute, but since it has several explicit constructors but lacks a parameterless constructor, it cannot be properly Serialized and then Deserialized (at least using an XmlSerializer).

    SubSonic.TableSchema.TableColumn seems to have the same issue. Other classes probably do as well, but I didn't do a complete inventory.

    In order to properly support serialization, these classes need to have a have a parameterless constructor and/or implement the ISerializable interface (if necessary).

  • 05-09-2008 1:35 PM In reply to

    Re: Serializable classes aren't Serializable

    When do you have to Serialize these objects directly?

    It is used when you want to Serialize the Generated objects.

    If I am I because I am I, and You are You because You are You, then I am I, and you are you. But If I am I because You are You, and You are You because I am I, then I am not I and You are not You. -Rabbi of Kotzk

  • 05-09-2008 1:59 PM In reply to

    Re: Serializable classes aren't Serializable

    Well, I was trying to Serialize them as part of troubleshooting an apparent bug in the generated TableSchema.Table initialization code (reported yesterday) so that I could do a diff on the XML of the 2 different instsnces I was looking at. Since that failed, I had to use the debugger to compare them prpoerty by property. Serializing them directly probably isn't a common occurrence, but if they are going to be decorated as Serializable, then they should be Serializable.

    Also, not supporting a parameterless constructor goes against the Framework Design Guidelines and the .NET best practices of allowing ciomponent initialization to be done via Properties (in arbitrary order) rather than by constructors only. Don't get me wrong, I like having extra constructors for convenience, but they shouldn't be the only way to init the object in a reusable API.

    Side Note: I have noticed that it appears that many of the SubSonic classes which have multiple constructors don't appear to use constructor chaining. Is this intentional, or simply an oversight?

  • 05-09-2008 2:10 PM In reply to

    Re: Serializable classes aren't Serializable

    Sounds like your right about the Default constructor.

    Justin_W:
    Side Note: I have noticed that it appears that many of the SubSonic classes which have multiple constructors don't appear to use constructor chaining. Is this intentional, or simply an oversight?
    Looks like an oversight.

    If I am I because I am I, and You are You because You are You, then I am I, and you are you. But If I am I because You are You, and You are You because I am I, then I am not I and You are not You. -Rabbi of Kotzk

Page 1 of 1 (4 items) | RSS