Geeks With Blogs


Add to Google

Tim Hibbard CEO for EnGraph software

I'm rewriting a class in our GPS object that handles the geographic coordinates of GPS points. We need more flexibility in converting between types of coordinates. I'm torn between designing the class for performance or for ease of consumption.

From an architectural point of view, the class should be easy to consume. So when somebody has this class loaded, they could use a .DecimalDegrees or .DMS property and it would take the existing data, convert it on the fly and spit it back.

However, I know that in our enterprise GPS solutions, the object is serialized and passed across the internet over .NET remoting. By default, public properties are serialized. So the conversion code behind the .DecimalDegrees is going to run for each coordinate point in the GPS dataset (actually twice, one for latitude, one for longitude). That would be a huge performance hit.

The first solution would be to put the conversion code in a function. A .ToDecimalDegrees. That would work, but it makes it harder to consume. Developers don't want to dig through functions in an API to get what they want.

The better way is to use the Xml.Serialization.XmlIgnore attribute on the .DecimalDegrees property. This will tell the serializer to ignore this property and that it's value should not be part of the xml output. This way we have our performance and our good class design.

I would be interested in knowing how other people deal with situations like this.

Posted on Wednesday, July 5, 2006 11:46 AM EnGraph , .NET , GPS , | Back to top

Comments on this post: Class design for serialized objects

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Tim Hibbard | Powered by: