defining objects with xml/schema

[Jarlaxle]

This is more of wanting to get some opinions and if anyone has run into the
same design issue.

I need to have about a hundred c# classes that simply represent an object
and contain data (no methods). These objects will be modified pretty often
by alot of different people and need to be serialized/deserialized to binary
and xml.

I basically have three options:

1. write the classes in c#
2. represent the classes in xml and auto-generate them
3. represent the classes in xsd and auto-generate them

option 1 can be done but gets very reptitive and messy when there are many
sub-objects.
option 2 gives a very clear representation of the object and is easy for
other people to modify/add new fields, however does not contain enough data
to distinguish the types that are generated (data type, array, etc.).
option 3 does the job but is so hard to visualize and maintain/modify and
will be hard for other people who don't have a grasp of xsd schema. plus xsd
schema is really to represent xml and not a programmable object.

I was thinking of representing my object with a hybrid of xml and xsd and
having a custom generator like xsd.exe create the c# objects. an object
could look like this...

<myobject>
<item1>xs:type=boolean</item1>
<item2 myattr1="xs:type=dateTime">xs:type=string</item2>
<item3>
<item4 xs:array>xs:type=mytype</item4>
</item3>

something like that...of course "xs:" could be something different but
indicates a code generator option. it would produce somethig like...

class myobject
{
public bool item1 {get; set;}
public item2Object {get;set;}
public item3Object {get;set;}

public class item2Object
{
[XmlAttribute]
public bool myattr1 {get; set;}

[XmlText]
public string Value {get;set;}
}
public class item3Object
{
public List<mytype> item4 {get; set;}
}
}

I think that would give a good flexible way of generating objects that could
be easily maintained and easily compared for backward compatibility problems.

any thoughts?

 

[parez]

This is more of wanting to get some opinions and if anyone has run into the
same design issue.

I need to have about a hundred c# classes that simply represent an object
and contain data (no methods). These objects will be modified pretty often
by alot of different people and need to be serialized/deserialized to binary
and xml.

I basically have three options:

1. write the classes in c#
2. represent the classes in xml and auto-generate them
3. represent the classes in xsd and auto-generate them

option 1 can be done but gets very reptitive and messy when there are many
sub-objects.
option 2 gives a very clear representation of the object and is easy for
other people to modify/add new fields, however does not contain enough data
to distinguish the types that are generated (data type, array, etc.).
option 3 does the job but is so hard to visualize and maintain/modify and
will be hard for other people who don't have a grasp of xsd schema. plus xsd
schema is really to represent xml and not a programmable object.

I was thinking of representing my object with a hybrid of xml and xsd and
having a custom generator like xsd.exe create the c# objects. an object
could look like this...

<myobject>
<item1>xs:type=boolean</item1>
<item2 myattr1="xs:type=dateTime">xs:type=string</item2>
<item3>
<item4 xs:array>xs:type=mytype</item4>
</item3>

something like that...of course "xs:" could be something different but
indicates a code generator option. it would produce somethig like...

class myobject
{
public bool item1 {get; set;}
public item2Object {get;set;}
public item3Object {get;set;}

public class item2Object
{
[XmlAttribute]
public bool myattr1 {get; set;}

[XmlText]
public string Value {get;set;}
}
public class item3Object
{
public List<mytype> item4 {get; set;}
}

}

I think that would give a good flexible way of generating objects that could
be easily maintained and easily compared for backward compatibility problems.

any thoughts?

Let me start of by saying that i am not an expert..

I was in a similar situation. I started off with with option 3, spend
some time writing a custom code generator (i had some speacial
requirements) and then i switched to option.

The reason I switched was becuase
1)I am more comforable writing c# code than xsd.
2) I was NOT going to use the XSD for validation on my end or the
server end.
3)I mite end up using the a code generator like codesmith to generate
the remaining classes from the DB schema.
4) my boss asked me.

 

[parez]

This is more of wanting to get some opinions and if anyone has run into the
same design issue.

I need to have about a hundred c# classes that simply represent an object
and contain data (no methods). These objects will be modified pretty often
by alot of different people and need to be serialized/deserialized to binary
and xml.

I basically have three options:

1. write the classes in c#
2. represent the classes in xml and auto-generate them
3. represent the classes in xsd and auto-generate them

option 1 can be done but gets very reptitive and messy when there are many
sub-objects.
option 2 gives a very clear representation of the object and is easy for
other people to modify/add new fields, however does not contain enough data
to distinguish the types that are generated (data type, array, etc.).
option 3 does the job but is so hard to visualize and maintain/modify and
will be hard for other people who don't have a grasp of xsd schema. plus xsd
schema is really to represent xml and not a programmable object.

I was thinking of representing my object with a hybrid of xml and xsd and
having a custom generator like xsd.exe create the c# objects. an object
could look like this...

<myobject>
<item1>xs:type=boolean</item1>
<item2 myattr1="xs:type=dateTime">xs:type=string</item2>
<item3>
<item4 xs:array>xs:type=mytype</item4>
</item3>

something like that...of course "xs:" could be something different but
indicates a code generator option. it would produce somethig like...

class myobject
{
public bool item1 {get; set;}
public item2Object {get;set;}
public item3Object {get;set;}

public class item2Object
{
[XmlAttribute]
public bool myattr1 {get; set;}

[XmlText]
public string Value {get;set;}
}
public class item3Object
{
public List<mytype> item4 {get; set;}
}

}

I think that would give a good flexible way of generating objects that could
be easily maintained and easily compared for backward compatibility problems.

any thoughts?

Let me start of by saying that i am not an expert..

I was in a similar situation. I started off with with option 3, spend
some time writing a custom code generator (i had some speacial
requirements) and then i switched to option.

The reason I switched was becuase
1)I am more comforable writing c# code than xsd.
2) I was NOT going to use the XSD for validation on my end or the
server end.
3)I mite end up using the a code generator like codesmith to generate
the remaining classes from the DB schema.
4) my boss asked me.

Correction..
spent time
switched to option 1

 

[Joseph Daigle]

I've used XSD.exe to generate code for a few smaller scale XML projects, and
it has served me quite well. Obviously the hardest part is properly creating
the schema such that it produces sane-looking XML sane-functioning classes
from the tool.

As a starting point you can also use XSD.exe to infer and a schema from a
supplied XML file. From there you can seperate out your classes, and then
generate the C#.

Some ideas.

 

[Jarlaxle]

i just think seeing the object in a compact tree structure like xml helps in
visualizing the component, easier to make changes and coud save time.

obviously this is accepted since there are tools like xsd.exe and
xsdobjgen.exe I think it just lacks the ability to specify details.

This is more of wanting to get some opinions and if anyone has run into the
same design issue.

I need to have about a hundred c# classes that simply represent an object
and contain data (no methods). These objects will be modified pretty often
by alot of different people and need to be serialized/deserialized to binary
and xml.

I basically have three options:

1. write the classes in c#
2. represent the classes in xml and auto-generate them
3. represent the classes in xsd and auto-generate them

option 1 can be done but gets very reptitive and messy when there are many
sub-objects.
option 2 gives a very clear representation of the object and is easy for
other people to modify/add new fields, however does not contain enough data
to distinguish the types that are generated (data type, array, etc.).
option 3 does the job but is so hard to visualize and maintain/modify and
will be hard for other people who don't have a grasp of xsd schema. plus xsd
schema is really to represent xml and not a programmable object.

I was thinking of representing my object with a hybrid of xml and xsd and
having a custom generator like xsd.exe create the c# objects. an object
could look like this...

<myobject>
<item1>xs:type=boolean</item1>
<item2 myattr1="xs:type=dateTime">xs:type=string</item2>
<item3>
<item4 xs:array>xs:type=mytype</item4>
</item3>

something like that...of course "xs:" could be something different but
indicates a code generator option. it would produce somethig like...

class myobject
{
public bool item1 {get; set;}
public item2Object {get;set;}
public item3Object {get;set;}

public class item2Object
{
[XmlAttribute]
public bool myattr1 {get; set;}

[XmlText]
public string Value {get;set;}
}
public class item3Object
{
public List<mytype> item4 {get; set;}
}

}

I think that would give a good flexible way of generating objects that could
be easily maintained and easily compared for backward compatibility problems.

any thoughts?

Let me start of by saying that i am not an expert..

I was in a similar situation. I started off with with option 3, spend
some time writing a custom code generator (i had some speacial
requirements) and then i switched to option.

The reason I switched was becuase
1)I am more comforable writing c# code than xsd.
2) I was NOT going to use the XSD for validation on my end or the
server end.
3)I mite end up using the a code generator like codesmith to generate
the remaining classes from the DB schema.
4) my boss asked me.

Correction..
spent time
switched to option 1