Question

For example, say that I’m writing an application that allows users to design their own business card, allowing them to add visual objects to the “template” that they are currently designing, each of these objects are bound to various bits of user-data.

eg. They drag an “Address Box” that automatically puts in the address of the user, then a “Name Text” which again, automatically uses the users defined Name.

The reason for this is that a customer may create 15 templates all with their own “look”, however if they want to change their address, they only need to modify it in one place.

All of these visual objects and the template itself, are written in XAML. I need to store these user-created templates into the database so that they can retrieve them and edit them later. The way I see it, I have two options:

1. Store the entire template as XAML in a database table called “templates” along with an ID and an OwnerID.

2. Create a table for an abstract type of “visual object”. Create a table for each concrete type of visual object (ie. “AddressBox”) which would inherit from the abstract type and have fields for each of the user-configurable properties (font size, x/y coords, etc). Finally, create a table called template, which holds a collection of visual objects.

It should be noted that I’ve been using the Entity Framework to design this, so apologies if I’ve thrown some EF keywords in there!

Personally, for the time being XAML storage may well be enough to satisfy our requirements, however everything I’ve seen seems to suggest it’s a really bad way to store data in a database.. ie. Skip to 35mins in this: http://youtu.be/uFLRc6y_O3s isn’t this exactly what he’s suggesting not to do?

With XAML storage I gain property value inheritance, which could potentially make things slightly easier, although I’m not sure if the users will understand how values might “flow” down the chain. Obviously XAML also allows me to store any property value I like; I don’t have to add it to the database first.

The downsides are that I think it could be a lot harder to manage the data if it’s all XAML; worst case potentially having to retrieve every piece of XAML, parse all of them, find a value I need to change / look at, re-parse, save the updated “blob” of XAML back. This will obviously result in much larger read/write operations.

Answer 1

I’d go for storing the XAML directly. Reason is that the only advantage that you get from storing an abstract layout, is that you could replace the UI framework, and you guard yourself from a potential breaking change in XAML.
But as a breaking change introduced by Microsoft would break all controls out there, so there will be some upgrade possiblity that you quite likely can utilize as well.

For me option 2 is for sure the nicer version, but I tend to be a “YAGNI”-guy. So develop stuff when you need it, and if you are on WPF go for it.

hth,
Martin