Чем старше Spring, тем больше контекстов
Уже много лет работая со спрингом, я заметил забавную закономерность: в каждой новой версии добавляется новый способ конфигурирования контекста. Давайте вспомним, как это было: В первом спринге конфигурацию можно было писать исключительно на xml-e. (ClassPathXmlApplicationContext («context.xml»))
Во втором (точнее с 2.5) появилось возможность создавать контекст через аннотации. (AnnotationConfigApplicationContext («package.name»))
Третий спринг добавил конфигурацию на джаве. (AnnotationConfigApplicationContext (JavaConfig.class))
Четвёртый тоже сохранил традицию и уже с декабря 2013 года можно конфигурировать при помощи груви скриптов (GenericGroovyApplicationContext («context.groovy»))
Консультируя и проводя тренинги в различных компаниях, я видел самое разное отношение к этим способам конфигурирования. Крупные компании, зачастую живущие по принципу «работает — не трогай», до сих пор лелеют старые xml -конфигурации, продолжая их множить и кормить новыми бинами. «Зато у нас все централизовано!» — кричат их архитекторы, добавляя 100500-тысячную строчку в xml-Бога.
Компании поменьше, пытающееся угнаться за новшеством технологий, беспощадно сжигают старые XML-ы, переписывая всё что могут, на аннотации, а что не могут на Java-конфиг. И уже потирают руки, пытаясь придумать, а куда бы им теперь приткнуть конфигурацию на грувях.
Видел я и совсем забавные ситуации, когда не очень разбирающийся во всей этой каше конфигураций джуниор дублировал декларацию бинов, прописывая их и в xml-e и через аннотации (ну так чтобы наверняка).
А где же находится правда? Неужели как всегда посередине?
Давайте попробуем разобраться…
Для начала давайте сравним стратегии декларации бинов.Начнём с классического XML-a: Читать дальше →
