Конфигурация / регистрация контейнера IoC
Мне абсолютно необходимо использовать контейнер IoC для разделения зависимостей во все более сложной системе корпоративных сервисов. Проблема, с которой я столкнулся, связана с конфигурацией (также известной как регистрация). В настоящее время у нас есть 4 разных среды - от разработки до производства и между ними. Эти среды имеют множество конфигураций, которые немного отличаются от среды к среде; однако во всех случаях, когда Я сейчас могу думать о, зависимости между компонентами не отличаются от среды к среде, хотя я мог что-то пропустить и / или это могло явно измениться.
Итак, главный вопрос: есть ли у кого-нибудь подобный опыт использования фреймворка IoC? Или может кто-нибудь порекомендовать одну структуру вместо другой, которая обеспечила бы гибкую регистрацию, будь то посредством какого-то соглашения или упрощенной информации о конфигурации? Смогу ли я по-прежнему пользоваться свободным интерфейсом, или я застрял в XML - я бы хотел избежать XML-ада.
Редактировать: Это среда .Net, и я смотрел на Windsor, Ninject и Autofac. Кажется, что все они теперь поддерживают оба метода регистрации (свободный и XML), хотя поддержка Autofac лямбда-выражений, похоже, немного отличается от других. Кто-нибудь использует это в аналогичной среде с несколькими развертываниями?
Ответы 4
Я не уверен, подойдет ли это вашему конкретному случаю, вы не упомянули, на какой платформе вы работаете, но я добился большого успеха с Структура МОК в Виндзорском замке. Зависимости настраиваются в файле конфигурации (это .NET framework)
Посмотрите на обыкновенных носорогов Айендес. Он использует абстракцию над контейнером IoC. Так что вы можете переключать контейнеры, когда захотите. Что-то вроде container.Resolve всегда есть в каждом контейнере.
Я использую Structuremap для грязной работы, у нее свободный интерфейс и XML, и она достаточно мощная для большинства вещей, которые вы хотите делать. У каждого есть свои плюсы и минусы, поэтому небольшая абстракция, чтобы вы могли легко переключаться (никогда не знаете, как долго они будут рядом), это хорошо. В остальном, я думаю, Spring.Net, Castle windsor, Ninject и StructureMap больше не так уж далеки друг от друга.
Я использую Ninject. Мне нравится то, что мне не нужно использовать Xml для настройки зависимостей. Я могу просто использовать прямой код C#. Так же есть несколько способов. Я знаю, что эта функция есть в других библиотеках, но Ninject предлагает быстрое создание экземпляров, он довольно легкий, имеет условную привязку, поддерживает компактную структуру и поддерживает Silverlight, 2.0. Я также использую оболочку поверх нее, на случай, если в будущем я переключу ее на другой фреймворк. Выбирая фреймворк, вам обязательно стоит попробовать Ninject.
Если вы хотите абстрагироваться от своего контейнера и иметь возможность использовать другие, подумайте о том, чтобы он был инъекционным способом, который я пытался сделать здесь
Я быстро прочитал ваш пост - интересный подход, который вы использовали. С тех пор, как я разместил этот вопрос, я в конечном итоге использовал Ninject в крупном проекте и быстро увидел преимущество абстрагирования от конструкций, специфичных для контейнера. Придется более внимательно посмотреть на то, что вы сделали. Спасибо!