Продолжение первого поста о StructureMap

В первой части были освещены темы:

• Установка
• Регистрация (Основа, Профили, Плагины, Сканирование, Внедрение)

В этой части пойдет речь о:

• Конструкторы (Простые типы, Конструктор по умолчанию, Составные типы, Приведение типов, Задание аргументов)
• Свойства (Простое задание свойств, Встроенное задание свойств, Задание свойств фреймворком, Допостроение существующих классов)
• Время жизни

Конструкторы

Очень важный вопрос в реальном программировании применительно к разрешению зависимостей в IoC контейнерах, как быть с классами, у которых несколько конструкторов. Как их инициализировать, как задавать параметры, как дорабатывать и прочее и прочее. Надеюсь что на большинство вопросов ниже будет дан ответ. StructureMap действительно мощная и гибкая штука.

Перед тем как начать описывать возможности фреймворка, надо поговорить о тестовых классах. В этот раз они будут сложнее. Наследование, конструкторы с простыми типами, с составными.

Итак, пусть у нас будут следующие классы:

public interface IClassA : IClass {
     int A { get; set; }
}

public interface IClassB : IClass {}

public class ClassA : IClassA {
    public int A { get; set; }
    public int B { get; set; }
    public Class1 Class1 { get; set; }

    [DefaultConstructor]
    public ClassA() {}

    public ClassA(int a) {
         A = a;
    }
}

public class ClassB : IClassB {
     public IClassA ClassA;

     public ClassB(IClassA classA) {
         ClassA = classA;
     }
}

public class ClassM : IClassA {
    public int A { get; set; }

    public ClassM(int a) {
        A = a;
    }

    public ClassM(int a, int b) {
        A = a + b;
    }
}

Они с некоторой избыточностью на данный момент, которая пригодиться чуть дальше в повествовании.

Итак, начнем с самых простых вариантов.

Сегодня я хочу рассказать о IoC контейнере StructureMap (и это не перевод устаревшей официальной документации), который мне приглянулся гораздо больше чем Unity. Хотя, честно сказать, мои взаимоотношения с Unity не сложились с самого начала, когда я увидел километровые файлы конфигурации к нему или же двухсот знаковые строки конфигурации в коде. Не будем о грустном.

StructureMap не только мне показался более удобным чем другие реализации DI\IoC, достаточно набрать в гугле StructureMap vs Unity и получить кучу ссылок, где люди обсуждают и показывают наглядно, что в работе самым удобным, гибким и естественным является StructureMap.

Ссылка раз, два и три. Ко всему прочему StructureMap еще и достаточно быстрый.
Вот еще очень интересные подборки материалов по сравнению фреймворков http://www.sturmnet.org/blog/2010/03/04/poll-results-ioc-containers-for-net

Я думаю можно опустить рассуждения о том, стоит ли такие контейнеры использовать в своем проекте или нет, и стоит ли писать свою реализацию. Я могу сказать, что в моей практике сначала случилось так, что были самописные реализации, которые заметно уступали по возможностям и удобству, но они решали свои конкретные задачи и этого на тот момент хватало.  С развитием проекта, как-то было недосуг переводить все на какую-то другую технологию. Потом был Unity, Unity, но в конце концов я пришел к тому, что надо попробовать StructureMap и не пожалел об этом ни разу.

В чем, на мой взгляд, плюсы StructureMap:

• Настройка с помощью DSL
• Очень гибкая настройка всего
• Простота конечного использования
• Возможности для проверки внутренних связей
• Поддержка тестирования out-of-the-box

Еще много есть интересных и полезных вещей в StructureMap, но их было бы неправильно отнести к плюсам, лучше назвать их приятным дополнением, которые только облегчают жизнь.