Hello, Unity 2.0

Рассматривая ранее принцип инверсии зависимости, мы остановились на том, что нам нужен некий IoC/DI фреймворк, который помог бы нам избавиться от рутинной работы. Как я уже говорил, существуем множество различных IoC/DI фреймворков:

1. Microsoft Unity
2. Ninject
3. Autofac
4. StructureMap
5. Castle
6. Spring.Net

В этой статье мы познакомимся с open-source IoC/DI контейнером от Microsoft Unity 2.0 под .NET 4.0. Работать с данным фреймворком очень легко, и я продемонстрирую это Вам на простом примере, проделав простых 5 шагов:

1. Создадим новый проект и добавим в него основные сущности. Смотри предыдущую статью.
2. Скачаем необходимые библиотеки.
3. Добавим references на них в проекте.
4. Настроим IoC-контейнер через конфигурационный XML-файл.
5. С помощью IoC-контейнера получим экземпляр объекта нашего класса.

Первым делом создайте новый проект под именем UnityExample, в который добавьте, описанные в предыдущей статье, классы и интерфейсы в общее пространство имен UnityExample.
Вторым шагом, нам понадобиться сам контейнер Unity, его можно скачать в составе
Microsoft Enterprise Library 5.0 виде инсталляционного файла, установка которого производиться в режиме wizard installer и не требует наличия особых навыков, и в отличие от ручной установки, она автоматически зарегистрирует необходимые сборки в GAC добавит дополнение к Visual Studio. После установки добавим ссылки на необходимые библиотеки Unity:

1. Microsoft.Practices.Unity.dll
2. Microsoft.Practices.Unity.Configuration.dll

Далее можно приступать к работе.
Вообще, настраивать поведение IoC-контейнера можно и в коде, но все-таки хорошим тоном считается, если изменение конфигурации не приведет к изменению кода и повторной сборки проекта, поэтому всю конфигурацию мы вынесем в отдельный файл, причем не захламляя основной файл конфигурации App.config:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

 

    <configSections>

        <section

            name="unity"

            type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />

    </configSections>

 

    <!-- Вынесем все в отдельный файл -->

    <unity configSource="Unity.config" />

 

</configuration>

Сама настройка контейнера будет описана в файле Unity.config (не забудьте выставить опцию "Copy to Output Directory"). Следует отметить, что конфигурационный файл для Unity контейнера имеет XML-формат, при необходимости, если Ваш редактор XML файлов поддерживает XSD схемы и intellisense, то Вы можете упростить процесс конфигурирования, воспользовавшись XSD схемой (ставится вместе с Microsoft Enterprise Library 5.0) "c:\Program Files\Microsoft Visual Studio 9.0\xml\Schemas\UnityConfiguration20.xsd":

<?xml version="1.0" encoding="utf-8" ?>

 

<unity xmlns="http://schemas.microsoft.com/practices/2010/unity">

 

    <!-- Заведем псевдонимы для известных типов -->

    <alias alias="IProcessor" type="UnityExample.IProcessor, UnityExample" />

    <alias alias="Processor" type="UnityExample.Processor, UnityExample" />

    <alias alias="Computer" type="UnityExample.Computer, UnityExample" />

 

    <container>

        <!-- Свяжем тип IProcessor с типом Processor -->

        <register type="IProcessor" mapTo="Processor"></register>

 

 

        <!-- Свяжем тип Computer с типом Computer -->

        <register type="Computer" mapTo="Computer">

            <constructor>

                <!-- Объявим аргумент конструктора processor типа IProcessor как зависимый -->

                <param name="processor" type="IProcessor">

                    <dependency/>

                </param>

            </constructor>

        </register>       

    </container>   

</unity>

Так как это все-таки ознакомительный пример, я решил поместить все сущности в один файл, в итоге получилось следующее:

using System;

using System.Configuration;

 

using Microsoft.Practices.Unity;

using Microsoft.Practices.Unity.Configuration;

 

namespace UnityExample

{

    /// <summary>

    /// Интерфейс процессора.

    /// </summary>

    interface IProcessor

    {

        /// <summary>

        /// Частота процессора.

        /// </summary>

        int ClockRate

        {

            get;

        }

    }

 

    /// <summary>

    /// Конкретный процессор с частотой 166 Мгц.

    /// </summary>

    class Processor : IProcessor

    {

        public int ClockRate

        {

            get

            {

                return 166;

            }

        }

    }

 

    /// <summary>

    /// Конкретный компьютер.

    /// </summary>

    class Computer

    {

        /// <summary>

        /// Процессор.

        /// </summary>

        protected IProcessor _processor;

 

        public Computer(IProcessor processor)

        {

            _processor = processor;

        }

 

        public void PrintDescription()

        {

            Console.Write("Clock rate: {0} Mhz", _processor.ClockRate);

        }

    }

 

    class Program

    {

        static void Main(string[] args)

        {

            // IoC контейнер.

            IUnityContainer container = new UnityContainer();

            // Загрузим конфигурацию для IoC контейнера из секции unity.

            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");

            // Применим конфигурацию.

            section.Configure(container);

 

            // Получим экземпляр объекта типа Computer.

            Computer computer = container.Resolve<Computer>();                   

            computer.PrintDescription();

        }

    }

}

И если вы запустите проект, то Вы увидите на консоли сообщение "Clock rate: 166 Mhz", тем самым IoC-контейнер сам разрешил тип Computer, более того, контейнер автоматически разрешил зависимость Computer от IProcessor. Очень важно отметить, что мы НЕ использовали оператор new, который задал бы жесткую зависимость. Все это позволяет строить более гибкие архитектурные решения, которые способны полностью перестраиваться при небольшом изменении в конфигурационном файле.

В следующей статье я отвечу на популярные вопросы, касающиеся конфигурирования Microsoft Unity. Продолжение следует IoC/DI