Продолжение разговора про Spring IoC Framework

В первой статье я задекларировал, что есть три подхода к написанию приложений в Java, если рассматривать разработку с позиции DI:

• писать, не используя DI — код более простой и понятный, но менее гибкий;
• писать код, используя DI, и дополнительно писать Java код, который связывает компоненты;
• писать код, используя DI, и связывать компоненты с помощью конфугарационных файлов в XML.

Для меня интересным является то, что все три подхода можно использовать в одном приложении. Можно к примеру в мелких модулях, которые возможно протестировать целиком, не применять DI, более крупные компоненты собрать с помощью Java-кода, а там, где уместно дать пользователю возможность выбирать из нескольких альтернативных реализаций использовать конфигурационный файл и Spring IoC.

Чтобы лучше понимать взаимоотношения и выбирать оптимальное соотношение между Spring IoC Framework и Java кодом, я часто рассматриваю Spring IoC не как "фреймворк", который инициализирует мое приложение и вызывает нужные методы, а как примитивный, динамический, интерпретируемый язык программирования предназначенный для того, чтобы скриптовать инициализацию Java приложений. Нам нужно скриптование в этом месте при инициализации — используем IoC. Не нужно скриптование — не усложняем наше приложение без необходимости.

IoC Spring Framework

Поговорим о IoC Spring Framework. Дело в том, что меня совсем не радует его использование во всех Java проектах, в которых я имел честь участвовать.

Начнем с того, что сам по себе инструмент не плох. Но вот его использование - это зачастую ужас. Чтобы что-то правильно использовать надо хорошо понимать для чего эта штука создана и где она помогает и где мешает. Хочу попытаться это сформулировать.