Джаб, ну заканчивай уже спамить на форуме
1. Открываешь Гугл
2. Пишешь там "Marin Fowler inversion of control"
3. Читаешь статьи, набираешься знаний
4. ???
5. PROFIT!!!

забыл никДалее IOC позволяет декларативно настроить транзакции, скоупы жизни бинов и т.д. и т.п.Ну вообще-то ни транзакции, ни скоупы к IoC никакого отношения не имеют.

Джаб, ну заканчивай уже спамить на форуме
1. Открываешь Гугл
2. Пишешь там "spring ioc scope prototype"
3. Читаешь статьи, набираешься знаний
4. ???
5. PROFIT!!!

забыл никsvenom, ты часом DI и IoC не путаешь?:) Декларативное описание транзакций и скоупов по сути и есть inversion of control.Не, не путаю. А вам поясню на всякий случай.
IoC - одна из методик уменьшения связанности между объектами. Это подход.
DI - одна из реализаций IoC. Другая распространенная реализация - Service Locator
Идем дельше - как реализуются DI? а) контейнеры; б) фабрики.

Spring IoC - это IoC, реализованный через DI, реализованный через контейнер.
Вам стало понятнее?

Идем дальше - что такое Spring IoC? Это модуль, который реализует непосредственно контейнер. Все. То есть это Context, BeanFactory и их реализации.

Идем дальше - транзакции в Spring. Что это? Это библиотека классов. И так как эти классы имеют конструкторы, геттеры и сеттеры, то вы, само собой, можете их использовать в спринговом контексте. Для упрощения работы с ними в спринге есть синтаксический сахар, с помощью которого можно вместо, например, объявления всяких интерсепторов и проксей в контексте, просто написать tx:annotation-driven, но идея остается та же - транзакции не имеют никакого отоношения к IoC. IoC это подход к управлению зависимостями между классами.

забыл никВсе то что ты красиво описал - это и есть Dependency InjectionПовторяемс: IoC -> DI -> SpringIoC (containter)
забыл ника вот IoC это как раз более масштабный принципЭта фраза вроде по делу, но вот только я уже об этом написал.
забыл никследуя которому некоторую специфическую часто повторяющуюся логику(зачастую инфраструктурную) обособляют от так называемой бизнес-логикиА вот это уже жесть пошла. Почитайте тут:
http://msdn.microsoft.com/en-us/library/ff648478.aspx
http://msdn.microsoft.com/en-us/library/dd458879.aspx
http://msdn.microsoft.com/en-us/library/ff648476.aspx

Теперь на пальцах попробую вам объяснить:
Есть интерфейс А, есть интерфейс В. Есть реализация AImpl, есть реализация BImpl, у которой один из членов класса - типа А. Вопрос: как сказать реализации BImpl, инстанс какого класса использовать на месте интерфейса A?
Решение в лоб:


Решение? Решение. Но вот незадача - у нас тут high coupling, так как BImpl обязан знать об AImpl, а потому все наши интерфейсы нахрен никому не сдались.

А вот другое возможное решение:


Что мы тут сделали? Мы делегировали контроль над тем, какую реализацию интерфейса A впихнуть BImpl за пределы BImpl. В этом и заключается IoC = Inversion of Control = Инверсия контроля . Что значит инверсия ? Значит вместо одного действия (создаем объект сами) мы переходим к обратному действию (просим создать объект за нас). Что значит контроль ? Контроль чего? Контроль вставки зависимости в класс.
Приведенный мною пример это IoC через ServiceLocator .

Вам становится яснее? Все таки прочитайте ссылки с MSDN, которые я привел выше, в особенности на картинки посмотрите. После того, как вы это сделаете, вы поймете, что фраза:
забыл никследуя которому некоторую специфическую часто повторяющуюся логику(зачастую инфраструктурную) обособляют от так называемой бизнес-логикиесть ни что иное, как бред.

забыл никвот почему декларативное управление транзакциями это часть IoCЕще раз.
Управление транзакциями это часть IoC = false .
Управление транзакциями это часть SpringIoC = false ;
Управление транзакциями есть в одной из частей Spring = true .

забыл никнасчет скоупов ты даже сами себе противоречишь, утверждая что IoC - одна из методик уменьшения связанности между объектами, так вот избавление от контроля за циклом жизни объектов, это и есть ничто иное, как методика уменьшения связанности между объектами.Логическая ошибка.
IoC это один из методов уменьшения связанности классов = true
Все, что уменьшает связанность классов, это IoC = false

забыл никИ да, DI это вовсе никакая не реализация IoC, а всего лишь его подмножество.Круто, то есть у нас получается примерно следующий разговор:
Я: Банановая кожура скользкая!
Вы: Нет! Неправильно! На банановой кожуре можно подскользнутся!
Кэп?

забыл никТы бы вместо того чтобы нервничать и подсовывать ссылки на статьи, в которых вначале прям таки написано что эта информация устаревшая То есть с момента публикации статьи понятия Inversion of Control, Dependency Injection и Service Locator как-то принципиально изменились?

забыл никВсе что делается не внутри обычного хода выполнения программы, а отдается на откуп фреймфоркам или контейнерам и есть IoC , а ты мне все про DI втираешьСначала пара логических утверждений:
DI это IoC = true
Если мы говорим про DI, следовательно мы говорим про IoC = true

А теперь по поводу вашей фразы, выделенной жирным - к сожалению, она бессмысленна. Поясните вот эти моменты:
1) Что такое "обычный ход выполнения программы"? Значит есть "необычный"? Как их отличить друг от друга и в чем заключаются их характерные черты?
2) Что значит "отдается на откуп фреймворкам"? Вот я попросил Spring заинжектить мне бин? Это "откуп"? А вот я попросил Хибер вытащить мне инфу из БД. Это "откуп"?

Еще раз, максимально сжато: IoC - это способ снижения связанности классов путем делегирования процесса установления зависимсотей между объектами от самих объектов к некому стороннему компоненту. Я не знаю, как это можно еще проще объяснить

VoDAIoC и прочая enterpriZe муть (тс...) показывает бонусы только на больших проектах. В проекте на 2-3 класса IoC yfabu не впился - new и все дела ;)IoC это наиболее известная и применимая реализация подхода "code to interfaces". То есть можно смело сказать, что использование IoC значительно улучшит качество 95% проектов без оного за счет серьезного снижения связанности компонентов, причем проектов любого размера.
Да, на маленьких проектах профита меньше, чем на средних и больших. Но буквально 5-10 взаимодействующих классов - IoC уже значительно облегчает жизнь - легче поддерживать, легче расширять и т.д.. Я только не знаю - 5-10 классов это уже большой проект в вашей терминологии или нет?

VoDAк примеру настройку соединения с БД проще держать в конфиге, а не в коде. чтобы не пересобирать проект каждый раз когда сменился пароль у пользователя.Утверждение к теме IoC ортогонально