Serialization, XSD to class, and deep copying?

[jjkboswell]

I have an XSD which I have generated a class from using the xsd.exe
tool. My XSD contains complex types within it, so that the generated
class has member variables which are of types that are also defined in
the XSD.

I deserialize XML data into instances of that class, and serialize back
to XML. So far so good.

However, in my code I have the concept of wanting to create new copies
of these deserialized objects and modifying some of the members of the
new copies. This obviously presents a problem because I don't want the
member variables referencing the same data.

In other words I *think* I want to do a deep copy, but everything I've
read on "C# copy constructors and ICloneable" seems to point to this
area being a route to no-where. Besides which, my generated classes
don't support ICloneable and I can't keep writing my own copy
constructors each time I generate the class.

So... is there a design pattern for this model that can help me
overcome these problems? It seems that I could make use of
serialization to create new copies, which is handy because my generated
classes, by nature, support serialization.

Any advice or references on "the right thing to do" would be much
appreciated.

Boz

[Kevin Spencer]

What makes you think that implementing "ICloneable " is a road to nowhere?
You can certainly add methods to your class. When it is serialized, the
method will not be there, but when it is deserialized, the method *will* be
there.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A brute awe as you,
a Metallic hag entity, eat us.
<jj********@yah oo.com> wrote in message
news:11******** **************@ j33g2000cwa.goo glegroups.com.. .

I have an XSD which I have generated a class from using the xsd.exe
tool. My XSD contains complex types within it, so that the generated
class has member variables which are of types that are also defined in
the XSD.

I deserialize XML data into instances of that class, and serialize back
to XML. So far so good.

However, in my code I have the concept of wanting to create new copies
of these deserialized objects and modifying some of the members of the
new copies. This obviously presents a problem because I don't want the
member variables referencing the same data.

In other words I *think* I want to do a deep copy, but everything I've
read on "C# copy constructors and ICloneable" seems to point to this
area being a route to no-where. Besides which, my generated classes
don't support ICloneable and I can't keep writing my own copy
constructors each time I generate the class.

So... is there a design pattern for this model that can help me
overcome these problems? It seems that I could make use of
serialization to create new copies, which is handy because my generated
classes, by nature, support serialization.

Any advice or references on "the right thing to do" would be much
appreciated.

Boz

[jjkboswell]

I said road to nowhere based on what I found on the net regarding deep
copying (copy constructor) for ICloneable and also item 28 in Effective
C# "Avoid ICloneable".

Further discussions in house have revealed a quite neat solution:
- derive a class from the XSD generated class
- implement ICloneable on the derived class
- our Clone() method uses serialization & deserialization create new
copy

Does this sound a reasonable solution? The only downsides I can see
might be in terms of performance, in that we're using serialization
twice and there's boxing/unboxing going on because Clone returns
System.Object.

Boz

PS Referenced posting regarding deep copy and ICloneable being road to
nowhere, from another MVP like yourself:
http://groups.google.co.uk/group/mic...e&rnum=5&hl=en

[Kevin Spencer]

Hi Boz,

Further discussions in house have revealed a quite neat solution:
- derive a class from the XSD generated class
- implement ICloneable on the derived class
- our Clone() method uses serialization & deserialization create new
copy

Does this sound a reasonable solution? The only downsides I can see
I couldn't tell you whether it's a reasonable solution in this specific
case. After all, you're still implementing ICloneable, regardless of whether
you're implementing it in the base class or the derived class.

And ICloneable may be something which can be abused, but it is also useful.
Otherwise it wouldn't be there.
PS Referenced posting regarding deep copy and ICloneable being road to
nowhere, from another MVP like yourself:
Well, Boz, speaking as an MVP (and a human being), I would have to say that
one should not take anything told to one by anyone, MVP or not, as Gospel.
When I post a suggestion, I expect the person I'm responding to to do some
research and ensure that I'm on the right track. I have been wrong a time or
two, and who hasn't? What I hope for is that what I tell someone will be
enough to stimulate or move that person in the right direction.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A brute awe as you,
a Metallic hag entity, eat us.
<jj********@yah oo.com> wrote in message
news:11******** **************@ t39g2000cwt.goo glegroups.com.. .I said road to nowhere based on what I found on the net regarding deep
copying (copy constructor) for ICloneable and also item 28 in Effective
C# "Avoid ICloneable".

Further discussions in house have revealed a quite neat solution:
- derive a class from the XSD generated class
- implement ICloneable on the derived class
- our Clone() method uses serialization & deserialization create new
copy

Does this sound a reasonable solution? The only downsides I can see
might be in terms of performance, in that we're using serialization
twice and there's boxing/unboxing going on because Clone returns
System.Object.

Boz

PS Referenced posting regarding deep copy and ICloneable being road to
nowhere, from another MVP like yourself:
http://groups.google.co.uk/group/mic...e&rnum=5&hl=en

[jjkboswell]

Kevin,

I was hoping to talk through ideas to help me reach a decision on how
to achieve a "deep copy", but perhaps discussing that here is going to
be a road to nowhere :-)

Anyway, I've been scouring the net on this subject and its very clear
that the subject is not clear cut. Check out this debate on obseleting
ICloneable. It expresses the issues involved and the differing
opinions.

http://www.dotnet247.com/247referenc...03/125427.aspx

Boz