While building Galactic Wars 3 version 2.0, I quickly ran into a serious problem with Xml serialization and more specifically deserialization. A few months ago I rolled my own solution for serializing data to and from Xml because the built in classes were bloated and yet not feature rich. A week or two ago I managed to get my class (XmlProvider) to compile for the Zune and Xbox 360. But there was still a problem…

1. References
   
   The first problem (the reason for the creation of XmlProvider) was that the built-in classes could not handle references. Every object had to be serialized straight through from top to bottom. Thus if you had an object with two properties that referenced the same object (in memory), the object would be serialized twice.
2. Inheritance
   
   The new problem is that with XmlProvider, deserialization was based on the information given by property attributes in your code. This is limiting because you may not know at compile time what exact type of object your property will be holding a reference to. In Galactic Wars 3 this is a problem when I am saving the profile of the user and want to save his specific ship.

So what is the solution? Start from scratch of course and solve these two problems at once! The first one is easy: provide a mechanism with which to uniquely identify any objects in memory and in Xml. We can then build a cache which we can reference from as we find objects with references. The solution to the second problem is also simple: rely on the type name in the Xml rather than the type on the property’s attributes. » Read more: Building an Xml Serialization Provider

One of the principals learned from designing my own Content Management Systems over the year was that deploying a CMS with a built in set of functionality is fine, but takes way too much work due to how different common functionality is. For instance, a forum is programmed quite differently from a poll or survey. In the last CMS I developed (FGCMS 2.0), I attempted to crack this problem by utilizing a hierarchial structure which could automatically be loaded from a database. What this mean was that I could extend a base class with new properties and functionality and store the new data in a new table. While this was wonderful from an extendability point of view, it was absolutely horrid from a consumer’s view.

Instead of having to program individual features, I had to program individual pages, static pages. This, of course, isn’t good because with every change to a class definition came a change to every associated page. The upkeep on this is terrible and what ended up happening was that I never got to implementing the pages for much of the backend functionality.

With Vodka, I am taking a step back and attempting to understand the problem from multiple perspectives. On one hand, XML based content is amazing for developing websites because XSL sheets can transform each piece of content into HTML without the need for static pages. On the other hand, having tangible .NET objects is priceless when it comes to code readability. Let’s face it, operating on XmlNode objects is not a fun procedure and is definately not maintainable. Furthermore, from a security stand point, I want to implement item live (and up) security that is customizable to the n^th degree. While this may not be possible, it will be possible for most common uses. This desire comes from working with SharePoint, where security is powerful, but hard to use. It is hard because there are only a predefined set of roles for each item and it isn’t easy to understand security in a grander scheme. You can’t grab a look at what rules are overriding others.

Here you can see that Vodka employs the very common three tier approach. The separation of data from logic from UI applications is clearcut. The reasons are fairly simple too:

• Simple to maintain
• Plug and Play behavior
• Common backend accross all applications
• Data format independency

But there is more to this than meets the eye. As shown above, the Business layer contains two sub layers: Simple Objects and Complex Objects. The goal of these is to provide a common ground of functionality with a split view of the data. On one side, the Simple Objects layer provides the Consumer layer with Xml based data. This makes developing websites, RSS feeds, and more incredibly simple. The other side is Complex Objects, which takes what I have learned from FGCMS 2.0 and bumps it up a notch. The core idea with the Complex Objects is that developers will want to and need to use tangible .NET objects with properties and methods. This fills that gap.

So how does this all work? Two words: Provider Model.

For now, let’s consider an implementation without security. The goal then is to represent data somewhere in memory, and be able to translate this data into other forms. Mainly the two forms in Vodka are Xml strings and .NET objects. Because data will be stored as an Xml string with attached metadata, it makes sense that the Simple Objects provider will always be a necessary step. The data provider model, then, takes data from some sort of memory (SQL Server, etc.) and translates it into a .NET object with metadata and an Xml string. A second step takes this object, and translates it into a Complex Object with properties, methods, et cetera.

The great thing about the provider model, of course, is that each provider is fully customizable. You are free to use built in providers or develop new ones as new needs/technologies arise. I plan to implement at least an SQL and Xml File Data Provider as well as a simple Xml deserializer / serializer Translation Provider for the first true release of Vodka.