To follow-up on yesterday's blog entry about why we should be spending our time learning Object Databases as opposed to building O/R Mappers.
If you think about many data-driven applications, how much of the data is really transactional data that is reported on using standard RDBMS/Sql syntax versus data that hydrates our objects? In other words, we need to acknowledge the inherent need of our business software to enable reporting; however, how much of our business data do we really care about reporting on? For example, is 80% of the data we report on reside in 20% of our data-structures? Given that, it is fair to say that the complexity of our software is more closely related to the complexity of our persistent object-structures. In other words, are we solving the wrong problem? Shouldn't we be looking more closely at OODMS and figuring out a way to report on it....or if RDBMS support is needed for reporting (e.g. corporate mandate) should we figure out a way to make our persistence framework match more closely with how we design and program our software and then solve the reporting issue in the database.....where it belongs.....
The ServerSide.Net has an interesting post about FastObject.Net, a product by Versant technology http://www.theserverside.net/news/thread.tss?thread_id=25578. I haven't had a chance to delve into it too much, but it looks promising.
Some interesting links:
http://www.versant.net/eu_en/solutions/dotNet_enhttp://community.fastobjects.com/community_fastobjects_net.htm-Mathew Nolton
There is so much hype about O/R Mappers these days. Visiting Igor Miovanovic's blog got me thinking about persistence frameworks I have written in the past. One in particular was pretty nice. It generated a great deal of code for you using templates that were modeled similarly to ASP.
However, why are we killing ourselves with O/R Mappers. It's silly really. The majority of the data for many data-driven applications are all about storing persistent object data. Why aren't we using tools that handle OO data. Why build a tool that maps object properties to data elements? We are really just creating a whole bunch of needless work for ourselves. If the vast majority of our data structures are about storing object data, then why in the h#$$ are we using relational database technology? If we do need to report off to an RDBMS, why not spend our time building or using a tool that will move data seamlessly from an OO store to a relational store for that purpose?
OO databases have been around for a while. Versant...ObjectStore come to mind. 6-7 years ago, they were quite the rage.....Why aren't they now....I still believe they are ahead of their time. For example, OO has been around for years; however if you are in the microsoft camp and you aren't a hard-core c/c++ programmer, you haven't really been exposed to OO (sorry VB 6 and prior is not OO....).
Now that the vast majority of VB'ers are hitting their stride with OO technologies, they are jumping on mapping data....good when your underlying datastore is SQLServer or Oracle....bad when you have a choice. Instead of fixing the symptom, we should be fixing the problem and the problem has to do with using a relational data-model to map to our OO structures when we should be using a datastore that is more consistent with how we model our software and that is an OO datastore.
IMHO....
The Configuration Management Application Block, CMAB, is a great tool for managing configuration data. If you wish to manage data outside of app.config or web.config, and IMHO it is the tool of choice. However, there are some design flaws with CMAB's XmlSerializableHashtable.
This class does a nice job of serializing native types. However, if you attempt to serialize your own classes, you will get a couple of nifty exceptions and the only way around these exceptions are to either modify the delivered source code...or extend the provided classes yourself. I chose the latter and I will attempt to describe how to do this. Also, (Daniel Cazzulino) has a nice blog about XmlSerializer that is a good read if you are interested in some of the details of XmlSerializer...which CMAB uses.
The first exception you might receive is something along the lines of: use the xmlinclude or soapinclude attribute to specify types that are not known statically. To get around this, you can do one of two things:
- Modify the call to XmlSerializer by passing in the additional types to consider. Or
- Extend XmlSerializableHashtable by deriving your own type and adding an [XmlIncludeAttribute()] to its definition.
Either method requires that you modify/create source code. I chose the latter because it was the easiest. For example:
[XmlInclude(
typeof(RuleAssembly))]
<--- I added my class definitionpublic class RulesSerializableHashtable:XmlSerializableHashtable
<--- I derived from this class{
....
}
A more elegant solution would be to provide a way to add additional class definitions in the configuration file and if i was going to get into the details of doing this, I would read into Daniels blog entry a bit more. However, creating a new class isn't as straightforward as you would think. By creating my own class, i have pretty much broken the configuration section handler provide with CMAB. I now need to create my own because the section handler will cast the values from my xml configuration data to XmlSerializableHashtable...any my derived type, RulesSerializableHashtable, will just get ignored....Oh well. So, to create the section handler, I took what CMAB provided and modified it to cast the hashtable to my derived type....again, i would rather rewrite the code to be more dynamic and i will when i have the time....but the code to do this is pretty straightforward.
So now, I have my own derived serializable hashtable and I rewrote the sectionhandler. Am I done? No, not quite yet...there is still a little work left to do. Some of you may have come across the infamous “Invalid cast exception” (e.g. of type InvalidOperationException).... Now I read a bunch of blogs and comments out there that attribute this to the XmlSerializer. The reality is, the XmlSerializer works just fine.
The problem is located in the indexer of XmlSerializableHashtable. Specifically:
set
{
lock( _ht.SyncRoot )
{
_ht.Clear();
foreach( Entry item in value )
{
_ht.Add (
GetValueFromXml(item.EntryKey),
GetValueFromXml(item.EntryValue); <---- Not right. If it's an object type, this will go Kaboom
}
}
}
The reason is will break is that GetValueFromXml(object val) will attempt to cast this value to an object array because if it is a native type, then its serialized state it is an object array (of xml attributes). However, if it is an object, it is already serialized into the correct object, you merely need to perform a cast. This means, I had to create my own method called GetValFromXml(object val) that checked the type first and if it could not be cast to an object array, it merely returned the passed in object. You could also modify the indexer to do the type checking. either way will work. For example:
protected object GetValFromXml(object value)
{
if((value as object[])==null)return value;
...............
}
Next, I overrode the indexer with the new keyword and changed my set code to call my method. I tried to override the GetValueFromXml but the base class made it a private method so it was hidden from me so i had to override the indexer. Or create my own class altogether and ignore what is provided (not a bad idea really).
To Summarize:
- Create your own Serializable Hashtable class. If you derive from XmlSerializableHashtable, make sure you override the indexer.
- Make sure your hashtable class either passes in the type to serialize in the constructor of XmlSerializer or use the XmlIncludeAttribute() decoration.
- Create your own section handler.
-Mathew Nolton
A friend of mine pointed this out, so if you are in the mood for a bit of R&R from software design and architecture, take a look at http://www.mulletwigs.com.
Personally, I like The Kentucky Waterfall (e.g. The Trash Mullet).