views:

36

answers:

3

What's the rationale (if any) of using XamlWriter.Save() to serialize a domain object? Please describe realistic scenarios. Thanks.

A: 

XamlWrite.Save is designed to serialize WPF objects such as Controls/Windows(that have xaml representation), check out : http://msdn.microsoft.com/en-us/library/ms754193.aspx. To serialize domain objects use XmlSerializer.

I have made a simple test :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Markup;
using System.IO;

namespace XamlTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Person p = new Person() { Id = 5, Name = "SomeName" };
            StringWriter sw = new StringWriter();
            XamlWriter.Save(p, sw);
            Console.Write(sw.GetStringBuilder().ToString());
            Console.ReadLine();
        }
    }

    public class Person
    {
        public int Id { get; set; }

        public string Name { get; set; }

        public string Phone { get; set; }
    }
}

prints the following :

<Person Id="5" Name="SomeName" Phone="{x:Null}" xmlns="clr-namespace:XamlTest;assembly=XamlTest" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" />  

Theres really no point in using it, I'm almost sure it uses a XmlSerializer behind the scenes.

Thiado de Arruda
I know... but since it is possible to use XamlWriter.Save() against any object, I'd like to see if there's someone around doing so, and why :)
Hemme
Take a look at this test I made. I think the major difference between XamlWriter and XmlSerializer is that it supports markup extensions and things specifics to Xaml. Its like using any Wrapper arround a XmlSerializer. You could use it, but would need unecessary references to wpf assemblies, so why not use the XmlSerializer directly?
Thiado de Arruda
A: 

There's little reason to serialize a domain object into XAML unless you're going to directly modify the serialized XAML. But there are plenty of circumstances in which you might do that.

For instance, suppose you have a view model object that you want to use while designing a UI in Expression Blend. Usually, what you'll do is write code that generates a test instance of the object and then reference that code in the Blend project. But you can also serialize the object to XAML and add the XAML file to the Blend project.

This can be pretty useful. Once you've done this, you can tweak the property values of your test object inside of Blend by editing its XAML representation instead of modifying the code that creates it. Of course you can accomplish more or less the same thing by using regular XML serialization - modifying the serialized XML file that your test object's constructor uses is almost exactly the same thing as modifying serialized XAML. The difference is that you can embed the XAML representation directly in other XAML files.

Another benefit that you get is that if XAML is your serialization format you can use markup extensions and value converters. Again, this is only going to be useful if you're modifying the serialized XAML, like in the scenario I just described.

Robert Rossney
A: 

Xaml enables encoding reflection info within the xml. You can serialize an object tree with items of types unknown at compilation time, then deserialize and identify the run time types from the xmlns:class.

Example:

MyClass
{
    public Object MyPropery
    {
        set;
        get;
    }
}

<MyClass>
    <MyClass.MyProperty>
        <ns:AnyClass />
    </MyClass.MyProperty>
</MyClass>

In addition to this, if you have a custom binding logic, you could make the xaml include it. (Like WPF and WF binding.)

Danny Varod