Inversion of Control - это шаблон проектирования, который спутан с понятием(шаблоном) Dependency Injection. Последний это специфический стиль первого.
В мире ява IoC Containers являются конкурентами EJB, и поэтому часто присутсвует убеждение, что они предоставляют механизм IoC приложению в отличии от EJB. Но EJB имеют всебе больше реализаций механизма IoC, чем эти контейнеры, дело в том, что контенеры предоставляют специфический вид IoC - это DI.
Более веселое название IoC- это "принцип Голливуда": "Don't call us, we'll call you". Вместе с приходом понятия этого механизма, появляется понятие фреймворка, который в отличии от библиотеки, не просто предоставляет методы, которые можно вызывать-использовать, а некий поток приложения, с помощью хуков(или оброботчиков) к которому присоединяется ваш код, который срабатывает на определенных этапов(при возникновении событий). Так и получается, что методология перевернулась с ног на голову, когда наше приложение управляло ходом приложения, и мы сами решали когда и где вызывать опеределенные методы библиотеки. Теперь же мы подписываем оброботчики и передаем управление фрейворку(контейнеру), который сам решает, когда вызывать наш код.
В мире ява IoC Containers являются конкурентами EJB, и поэтому часто присутсвует убеждение, что они предоставляют механизм IoC приложению в отличии от EJB. Но EJB имеют всебе больше реализаций механизма IoC, чем эти контейнеры, дело в том, что контенеры предоставляют специфический вид IoC - это DI.
Более веселое название IoC- это "принцип Голливуда": "Don't call us, we'll call you". Вместе с приходом понятия этого механизма, появляется понятие фреймворка, который в отличии от библиотеки, не просто предоставляет методы, которые можно вызывать-использовать, а некий поток приложения, с помощью хуков(или оброботчиков) к которому присоединяется ваш код, который срабатывает на определенных этапов(при возникновении событий). Так и получается, что методология перевернулась с ног на голову, когда наше приложение управляло ходом приложения, и мы сами решали когда и где вызывать опеределенные методы библиотеки. Теперь же мы подписываем оброботчики и передаем управление фрейворку(контейнеру), который сам решает, когда вызывать наш код.
Комментариев нет:
Отправить комментарий