Using ElasticObject to parse arbitrarily large XML documents into object graphs

ElasticObject is a great implementation of a DynamicObject, that allows the developer to work with an arbitrarily large XML document, using an object graph. The code below access the Norwegian Weather Forecast service Yr.no to get some forecast data for the location where I grew up in Norway, where a weather station nearby automatically collects meteorological data such as wind, temperature, pressure and wind direction, humidity and so on. The data is available among other ways as XML to download and ElasticObject can be used to handle the XML. When handling XML, it is possible to create an XSD from sample XML data and in for example Visual Studio create an XSD file through XML->Create Schema option in Visual Studio after opening the sample XML file. Using the Visual Studio Command line, it is possible to generate a class through the command:

xsd /classes myfile.xsd

This generates a file called myfile.cs, which will be a data contract.

The data contract generated can be used to deserialize the XML into an object. Often this is a preferred strategy, since one gets a strongly typed object (graph) to work with. ElasticObject is a dynamic object, and allows the developer to avoid having to generate a serialization class before deserializing the received XML. Sometimes, this also allows changes in the XML to occur without affecting the code. Often it is a limited part of the XML tree, which is the received XML the developer needs to retrieve for further processing. Also, not having to generate classes from the XML schema is also convenient. Still, the developer needs to refer more often to the XML to understand the structure of the object which is created. The Intellisense of ElasticObject is rather poor, so the developer needs to query the object graph using Immediate Window and query the object to find the right "path" to the information in the XML document. Similar techniques using System.Linq.Xml and XPath queries can be used. To start using ElasticObject, install first the NuGet package in Visual Studio. Type the following command in Package Manager Console.

PM> install-package AmazedSaint.ElasticObject
Installing 'AmazedSaint.ElasticObject 1.2.0'.
Successfully installed 'AmazedSaint.ElasticObject 1.2.0'.
Adding 'AmazedSaint.ElasticObject 1.2.0' to TestElasticObject.
Successfully added 'AmazedSaint.ElasticObject 1.2.0' to TestElasticObject.

The following code then illustrates the use:

using AmazedSaint.Elastic;
using System;
using System.IO;
using System.Net;
using System.Xml.Linq;

namespace TestElasticObject
{
    class Program
    {

        static void Main(string[] args)
        {
            var wc = new WebClient();
          
            using (StreamReader sr = new StreamReader(wc.OpenRead(@"http://www.yr.no/stad/Norge/Nord-Tr%C3%B8ndelag/Steinkjer/S%C3%B8ndre%20Egge/varsel.xml")))
            {
                var data = sr.ReadToEnd();
                IterateForecasts(data);          
            }

            Console.WriteLine("Press any key to continue ...");
            Console.ReadKey(); 

        }

        private static void IterateForecasts(string data)
        {
            dynamic weatherdata = XElement.Parse(data).ToElastic();
            foreach (var node in weatherdata.forecast.text.location[null])
            {
                Console.WriteLine(string.Format("Fra-Til: {0} - {1}", node.from, node.to)); 
                Console.WriteLine(~node.body);
                Console.WriteLine();
            }
        }

    }
}

The code above uses WebClient to download the target XML data, then uses a StreamReader to read the XML file into a string. Then using XElement and the ToElastic extension method in AmazedSaint.Elastic namespace, this is stored into a dynamic variable which can be worked on. One important gotcha here is how to drill down into the object graph of the ElasticObject, which I could not figure out following the documentation, since it only contained more simple examples but I found on StackOverFlow: To drill further down into the object graph than its immediate child node, type the path to the element which contains the data to work with using a dot separated syntax and in addition: use the null index to get to the child element which contains the data to process - for example to output. When traversing the child element in the foreach loop, its child elements will be stored into the loop variable node and then it is possible to get to the attributes of the node. To get the value inside the element, use the tilde (~) operator. ElasticObject implements some operators to make it easier to work with XML and object graphs. For example, to cast an ElasticObject to XML, the > operator can be used:

            dynamic store = new ElasticObject("Store");
            store.Name = "Acme Store";
            store.Location.Address = "West Avenue, Heaven Street Road, LA";
            store.Products.Count = 2;
            store.Owner.FirstName = "Jack";
            store.Owner.SecondName = "Reacher";
            store.Owner <<= "this is some internal content for owner";

            var p1 = store.Products.Product();
            p1.Name = "Acme Floor Cleaner";
            p1.Price = 20;

            var p2 = store.Products.Product();
            p2.Name = "Acme Bun";
            p2.Price = 22; 

            XElement el = store > FormatType.Xml; 
            System.Console.WriteLine(el.ToString());

The ElasticObject is defined dynamically and the <<= operator is used to set the value inside the property, which will be shown when converting the ElasticObject to XML. In addition, the code above shows how to create child elements, as the Products property contains two child Product objects, which will be Product XML elements. The < operator is used to "pipe" the object into an XElement variable, which is the converted XML object from the ElasticObject object graph. To convert the object from an XML document to an ElasticObject, the ToElastic() extension method can be used to convert the XML document or XElement variable into the ElasticObject - the object graph again. Using ElasticObject, it is possible to work with XML in object graphs and since it is dynamic, it is not necessary to create new types, such as serialization data contracts. ElasticObject source code is available on GitHub here: https://github.com/amazedsaint/ElasticObject
Its creator is Anoop Madhusudanan, AmazedSaint profile on GitHub. It originally was a project hosted on CodePlex. ElasticObject should be considered as an alternative when working with XML and object graphs. It is very tempting to avoid having to create new objects to work with the XML but work with a dynamic object that can be extended and changed. It should also be efficient. An alternative can be to use anonymous types, but why go the hard way when one can go the easy - elastic way?

IoC container example

This article will present an IoC container that can resolve concrete types via interfaces or instances recursively. It should not be used in production code without improved loop detection and error handling, but can in some scenarios be used if one needs a very simple (and fast) IoC container.

The code is heavily based on Jon Skeet's walkthrough of a IoC container ("IoC container on the fly").

First the code of the IoC container itself:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;

namespace TestComposedIoCContainer
{
    
    public class CompositionContainer
    {

        private readonly Dictionary<Type, Func<object>> providers = new Dictionary<Type, Func<object>>();

        private readonly object providersLocker = new object(); 


        public void Bind<TKey, TConcrete>() where TConcrete : TKey
        {
            lock (providersLocker)
            {
                providers[typeof(TKey)] = () => ResolveByType(typeof(TConcrete));
            }
        }

        public void Bind<T>(T instance)
        {
            lock (providersLocker)
            {
                providers[typeof(T)] = () => instance;
            }
        }

        private object ResolveByType(Type type)
        {
            var constructors = type.GetConstructors();
            if (constructors != null)
            {
                ConstructorInfo cInfo;
                cInfo = constructors.Count() == 1 ? constructors.Single() : 
                    constructors.Where(c => 
                    c.GetCustomAttributes(typeof(ImportConstructorAttribute), false).Length > 0).FirstOrDefault(); 
                if (cInfo == null)
                    throw new Exception(GetUsageMessage(type));
                var arguments = cInfo.GetParameters().Select(p => Resolve(p.ParameterType)).ToArray();
                return cInfo.Invoke(arguments);
            }
            else
            {
                var instanceField = type.GetField("Instance");
                if (instanceField != null)
                    return instanceField.GetValue(null);
                else
                    throw new Exception(GetUsageMessage(type));
            }
        }

        private static string GetUsageMessage(Type type)
        {
            return "Could not resolve a type implementing " + type.Name 
            + " - it must be registered through Bind to the composition container and either contain a single constructor or one constructor " 
            + "decorated with ImportContructor attribute or a field named Instance";
        }

        internal TKey Resolve<TKey>()
        {
            return (TKey)Resolve(typeof(TKey)); 
        }

        internal object Resolve(Type type)
        {
            Func<object> provider;
            if (providers.TryGetValue(type, out provider))
                return provider();
            else
                return ResolveByType(type);
        }

    }

}

The IoC container contains a dictionary which has got a Type as the Key, which is the usually either the interface or the concrete type to register through the Bind calls to the container, and a function expression that returns either an instance or resolves an instance through the container. When resolving a type, it can be multiple constructors in the class. I have extended Jon Skeet's code a bit, and by decorating the constructor by a ImportConstructor attribute, it is possible to specify which constructor is the constructor that should be the inversion of control constructor. Pass in all dependencies that must be resolved in that constructor. If the importing type or "part" to use a phrase from MEF, has no constructors that should be used, a field called "Instance" can be used. This is to support singleton patterns or similar. I have chosen to add locking when performing binds, to make this thread safe. Resolving instances is not made thread safe, as this can give very much locking. Usually a composition container is anyways set up in a single thread through registering bindings and then multiple threads will possibly access the IoC container. It is possible to put the CompositionContainer itself as a singleton, which is what one usually wants. I have added a generic singleton implementation in my blog that can be used to support this. The import constructor attribute is very simple:

using System;

namespace TestComposedIoCContainer
{
    
    public class ImportConstructorAttribute : Attribute
    {
    }
}

A unit test to display the use of this composition container, followed by the class definitions:

using NUnit.Framework;
using System;

namespace TestComposedIoCContainer
{
   
    [TestFixture]
    public class Program
    {

        [Test]
        public void MainTest()
        {
            var container = new CompositionContainer();
            container.Bind<ICalculator, Calculator>();
            container.Bind<IAdder, Adder>();
            container.Bind<IMultiplier, Multiplier>(); 

            var calculator = container.Resolve<ICalculator>();
            Console.WriteLine("Calculator resolved!");
            int resultAdd = calculator.Add(3, 5);
            Console.WriteLine("3 + 5 = {0}", resultAdd);

            int resultMult = calculator.Multiply(4, 8);
            Console.WriteLine("4 * 8 = {0}", resultMult);
        }

        public static void Main(string[] args)
        {

        }

    }

}


//CLASS DEFINITIONS

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace TestComposedIoCContainer
{
    
    public class Calculator : ICalculator
    {

        private IAdder adder;

        private IMultiplier multiplier;

        public Calculator()
        {

        }

        [ImportConstructor]
        public Calculator(IAdder adder, IMultiplier multiplier)
        {
            this.adder = adder;
            this.multiplier = multiplier; 
        }

        public int Add(int x, int y)
        {
            return adder.Add(x, y); 
        }

        public int Multiply(int x, int y)
        {
            return multiplier.Multiply(x, y); 
        }

    }


namespace TestComposedIoCContainer
{
    
    public interface ICalculator
    {

        int Add(int x, int y);

        int Multiply(int x, int y); 

    }

}


}


namespace TestComposedIoCContainer
{
    
    public class Adder : IAdder
    {

        public int Add(int x, int y)
        {
            return x + y; 
        }
    }

}


namespace TestComposedIoCContainer
{
    
    public interface IAdder
    {

        int Add(int x, int y);

    }

}


namespace TestComposedIoCContainer
{
    
    public interface IMultiplier
    {

        int Multiply(int x, int y);

    }

}


namespace TestComposedIoCContainer
{
    
    public class Multiplier : IMultiplier
    {

        public Multiplier()
        {

        }

        public int Multiply(int x, int y)
        {
            return x * y;            
        }

    }

}

//RESULT OF RUNNING NUNIT UNIT TEST ABOVE: 

------ Test started: Assembly: TestComposedIoCContainer.exe ------

Calculator resolved!
3 + 5 = 8
4 * 8 = 32

1 passed, 0 failed, 0 skipped, took 0,46 seconds (NUnit 2.6.2).

The code above should only be used for simple IoC scenarios. The IoC container uses very much reflection, which should not be consider the quickest way of resolving objects. The IoC container code can though resolve arbitrarily complex object graphs, when the registering of binds are done correctly, however there is a weakness here - the container does not do loop detection very good. For example, if a "part" or "component" of the composition container imports another parts and this part again resolves that part or some other recursive relation, looping will start to occur. But at the same time - many IoC frameworks are poor at detecting such errors anyways and will also give infinite recursion here. If you have simple needs for IoC resolution, the code above can be used in simple scenarios but most production code should instead choose among the many professional IoC frameworks out there.

Grunt.Js presentasjon

Grunt.js presentasjon

Grunt.Js presentasjon kan lastes ned her:

http://www.aurstad.info/GruntJs.pdf [PDF]

Note to my English readers, the GruntJs presentation is written in Norwegian.