Пару дней копаюсь в чужом коде (старом и немного витиеватом, надо сказать). Для того, чтобы разобраться что там к чему мне и понадобилось знать хотя бы немного о StructureMap.
До этого момента дела с IoC/DI (Inversion of Control/Dependency Injection) контейнерами (или фреймворками, кому как больше нравится) я не имела. Поэтому разбираться начала с азов.
Итак,
Что такое IoC container?
Если по существу, то это фрэймворк (библиотека, в общем набор классов и методов), который позволяет вам использовать принцип сокрытия зависимостей в вашем приложении. Доступно о том, что это за принцип и чем хорош, можно почитать здесь в самом начале статьи.
Кому и зачем нужны IoC container'ы?
Нужны они разработчикам достаточно больших приложений изобилующих множеством интерфейсов и множеством реализаций для одного и того же интерфейса. Имхо использовать такой фреймворк в небольшом приложении, просто "чтобы было" и "потому что модно" не имеет особого смысла.
Как использовать?
На Хабре есть серия статей о StructureMap. Там подробно и с примерами разбираются его возможности. Если кратко, то наша задача сводится к тому чтобы описать зависимости "интерфейс - какую реализацию для него использовать". В дальнейшем когда нам нужно создать экземпляр какого-нибудь класса, мы используем наш StructureMap контейнер, предварительно инициализированный передачей ему реестра (это набор тех самых соответвий интерфейс-реализация) в каком-нибудь бутстрапере (где-нибудь в начале программы в общем).
До этого момента дела с IoC/DI (Inversion of Control/Dependency Injection) контейнерами (или фреймворками, кому как больше нравится) я не имела. Поэтому разбираться начала с азов.
Итак,
Что такое IoC container?
Если по существу, то это фрэймворк (библиотека, в общем набор классов и методов), который позволяет вам использовать принцип сокрытия зависимостей в вашем приложении. Доступно о том, что это за принцип и чем хорош, можно почитать здесь в самом начале статьи.
Кому и зачем нужны IoC container'ы?
Нужны они разработчикам достаточно больших приложений изобилующих множеством интерфейсов и множеством реализаций для одного и того же интерфейса. Имхо использовать такой фреймворк в небольшом приложении, просто "чтобы было" и "потому что модно" не имеет особого смысла.
Как использовать?
На Хабре есть серия статей о StructureMap. Там подробно и с примерами разбираются его возможности. Если кратко, то наша задача сводится к тому чтобы описать зависимости "интерфейс - какую реализацию для него использовать". В дальнейшем когда нам нужно создать экземпляр какого-нибудь класса, мы используем наш StructureMap контейнер, предварительно инициализированный передачей ему реестра (это набор тех самых соответвий интерфейс-реализация) в каком-нибудь бутстрапере (где-нибудь в начале программы в общем).
Комментариев нет:
Отправить комментарий