Автообнаружение и регистрация классов в StructureMap

Уровень подготовки по шкале MS: 400

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

Уже по самому названию понятно, что это хорошо и несет благодать, так как обещает сократить трудовые расходы и написание тривиального кода, что всегда скучно и всегда забываешь его дописать где-то. Авторегистрация решит все эти проблемы, хотя, конечно, сначала придется попыхтеть.

Дальнейшие примеры покажут, как работать с обнаружением только по интерфейсу\базовому классу, а так же как работать при именовании классов по соглашениям (Convention over Configuration).

Вводная

Сначала достаточно простой пример. Пусть у нас есть множество классов для трансляции данных из базы, все они наследованы от базового класса. Т.е. что-то в духе:

 

И таких классов достаточно много, всех их регистрировать вручную не очень хочется, т.к. это выглядит ужасно в коде и писать долго. Регистрация таких адаптеров может занять экран, а то и два. Гораздо лучше поднапрячь извилины и записать это в несколько строк.

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

  • Тип должен быть явным, дженерик типы не регистрируются автоматически;
  • Тип должен иметь публичный конструктор;
  • Конструктор не может иметь аргументов примитивных типов;
  • Множественное регистрирование не допускается.

Указание сборки для сканирования можно задать несколькими способами:

  • Явно прописать имя сборки или же передать ее саму;
  • Обратиться к вызывающей сборке;
  • Найти сборку содержащую определенный тип;
  • Найти сборки по определенному пути.

MEF II

Продолжаем разговор о MEF и сегодня на повестке дня небольшие дополнения о экспорте/импорте, время жизни дополнений, способы создания дополнений, наследование дополнений.

Экспорт/импорт по контракту

До этого экспорт/импорт компонентов происходил по типу дополнения. Таким образом создавался конракт по умолчанию и можно было либо использовать единственное поле, куда экспортировалось дополнение, либо получать их пачкой и выбирать оттуда нужное дополнение по метаданным.

С помощью контрактов, можно назначать дополнения на конкретные, заранее определенные поля, без привлечения фильтров и воборок в ручную.

Итак, пусть у нас есть все те же два дополнения. Теперь только мы объявим контракты к ним. Это делается очень просто:

После это в мастер-приложении надо будет только указать поля, помеченные как импорт определенных контрактов.  Конечно про композицию не стоит забывать тоже.

Как видите, не надо теперь делать выборок по массиву загруженных дополнений. Они сами встали на свои места, как мы того ждем. В документации кажется приводятся примеры, когда можно не объявлять тип контракта, но тогда MEF не узнает, что чему сопоставлять. Выходом может стать тип dynamic.

 

Подробнее

NuGet создание

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

Создание своего пакета NuGet

Для примера, и, на мой взгляд в большинстве случаев, вы будете создавать NuGet пакет без зависимостей от других пакетов. Т.е. нам нужен будет любой проект, для простоты пусть это будет простая библиотека с N-ным количеством методов.

Для того, чтобы можно было библиотеку или набор библиотек включить в итоговый NuGet пакет,  необходимо добавить в проект файл с расширением “.nuspec”, где будут описаны все свойства и внутренние зависимости нашего пакета. Пока что в студии нет настроек для создание файлов требуемого расширения, так что можно создать любой текстовый файл, и сменить ему расширение.

В общем виде файл nuspec выглядит следующим образом:

 

Можно сказать, что комментарии тут излишни.  Единственное что стоит указать, какие тэги обязательны, а какие опциональные.

Подробнее

NuGet использование

Сегодня я хотел бы рассказать о использовании NuGet. Наверняка вы уже что-то слышали об этой системе управления внешними зависимостями. В последнее время система набирает обороты и все больше и больше разработчиков помещают свои системы в обертки для распространения с помощью NuGet.

Итак, NuGet – это менеджер для управления зависимостями от сторонних библиотек. С помощью этого инструмента можно устанавливать, обновлять и убирать зависимости для вашего проекта с большой легкостью. Применимо как для desktop программ, так и для web. В частности при разворачивании CMS Orchard, она половину сборок тащит при установке самостоятельно из библиотеки пакетов. Есть примеры использования NuGet для Silverlight.

Реплики с галерки

При изучении материалов по NuGet, основым плюсом выступает доступность общих библиотек для ваших проектов. Условные противники NuGet, или же принципиальная оппозиция спрашивает, зачем нужен NuGet для своих общих библиотек, если можно существует external для SVN и другие подобные штуки для систем контроля версий? Т.е. можно сослаться на стабильную ветку исходников.

Разработчики NuGet отвечают, что

  • не надо контроллировать доступ к системе контроля версий,
  • исходный код не показывается другим группам,
  • не надо следить и переключаться на другие ревизии вручную (может вы захотели соскочить с ветки Release, на более ранюю, или вы ссылаетесь на ревизию в trunk)

Неплохие плюсы. Тем более что теперь ваша любимая библиотека не затеряется среди репозиториев и проектов.

Подробнее