(Check here for an update to this post!)
I have a game in my mind that I keep trying to program. I'm sure many people have done this; the game never really gets anywhere, but it's always “getting there“. Anyway, I wrote many of the classes for this game in C#. Later, for no really good reason, I decided to translate these classes to VB. (Yes, I'm one of those guys.)
I discovered an interesting fact: C# and VB handle overloaded properties differently. Let's look at an example.
What I want to do is to make a read/write property in my base class, then override this property in a derived class. The property in the derived class should be read-only. In C#, this works as expected. However, in VB, this gives a compiler error that states that the base class cannot be overridden because the derived class's property differs from the base class's property by “readonly or writeonly.“ Why the difference?
In C#:
public abstract class Weapon
{
private bool _IsLimited = false;
public Weapon()
{
}
public virtual bool Limited
{
get
{
return _IsLimited;
}
set
{
_IsLimited = value;
}
}
}
public abstract class BeamWeapon: Weapon
{
public BeamWeapon()
{
base.Limited = false;
}
public override bool Limited
{
get
{
return base.Limited;
}
}
}
In VB:
Public MustInherit Class Weapon
Private _IsLimited As Boolean
Public Sub New()
End Sub
Public Overridable Property Limited() As Boolean
Get
Return _IsLimited
End Get
Set(ByVal Value As Boolean)
_IsLimited = Value
End Set
End Property
End Class
Public MustInherit Class BeamWeapon
Inherits Weapon
Public Sub New()
MyBase.Limited = False
End Sub
' This causes an error!
Public Overrides ReadOnly Property Limited() As Boolean
Get
Return MyBase.Limited
End Get
End Property
End Class
I recently created an application that needed a fairly deep class hierarchy. One class contained another class, which contained another, and so on. I needed to find an easy way to serialize this object and store it in a database. I found a post on Jeff Kirwan's blog that showed how to serialize an object to XML, which could then be placed into a database. This seemed to be an easy solution to my problem....
Then I got into trouble. I needed to store the class data in relational form in the database, so that some of this data could be referenced by other stored procedures. (The class hierarchy actually represents configuration data for an application.) This is easy to do with SQL via OPENXML. (See my Memphis .NET User's Group presentation.) However, pulling this data out of SQL proved to be a problem. The class structure was DEEP. It took a LOT of SQL code to rebuild the XML, so that the object could be deserialized. I had to find a better way.
I turned to the ISerializable interface. By implementing this interface, you can control how your class is serialized. Cool! This was the solution to my problem, right? Wrong! The ISerializable interface does not work when you use the XMLSerialier. I wanted XML and the ISerializable interface gave me a binary serialization.
After thinking a few unmentionable thoughts about the world in general, I finally found a real solution. There is an undocumented interface called IXmlSerializable. If you look this up in the .NET help, you will see that they say this is an internal interface and that you should not use it. However, if you look here, you can see that this interface IS documentated in Longhorn. Feeling a little better now, I tried it. It works great.
Serialization Methods:
XmlSchema IXmlSerializable.GetSchema()
{
return null;
}
void IXmlSerializable.ReadXml(XmlReader Reader)
{
// code to read in XML document goes here
}
void IXmlSerializable.WriteXml(XmlWriter Writer)
{
// code to write XML document goes here
}
Now I can have a deep class structure in my code, and serialize this as a very flat XML document. Then, instructing SQL Server to create this XML document from the database is very simple and easy to maintain.