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 nth 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.
