Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Чем старше Spring, тем огромнее контекстов

Anna | 2.06.2014 | нет комментариев
Уже много лет работая со спрингом, я подметил комичную обоснованность: в всякой новой версии добавляется новейший метод конфигурирования контекста. Давайте припомним, как это было:

  • В первом спринге конфигурацию дозволено было писать экстраординарно на xml-e. (ClassPathXmlApplicationContext(“context.xml”))
  • Во втором (вернее с 2.5) возникло вероятность создавать контекст через аннотации. (AnnotationConfigApplicationContext(“package.name”))
  • 3-й спринг добавил конфигурацию на джаве. (AnnotationConfigApplicationContext(JavaConfig.class))
  • Четвёртый тоже сберег традицию и теснее с декабря 2013 года дозволено конфигурировать при помощи груви скриптов (GenericGroovyApplicationContext(“context.groovy”))

Консультируя и проводя тренинги в разных компаниях, я видел самое различное отношение к этим методам конфигурирования. Большие компании, нередко живущие по тезису «работает – не трогай», до сих пор лелеют ветхие xml -конфигурации, продолжая их множить и кормить новыми бинами. «Но у нас все централизовано!» — кричат их архитекторы, добавляя 100500-тысячную строчку в xml-Всевышнего.
Компании поменьше, пытающееся угнаться за новшеством спецтехнологий, безжалостно сжигают ветхие XML-ы, переписывая всё что могут, на аннотации, а что не могут на Java-конфиг. И теснее потирают руки, пытаясь придумать, а куда бы им сейчас приткнуть конфигурацию на грувях.

Видел я и вовсе комичные обстановки, когда не дюже разбирающийся во каждой этой каше конфигураций джуниор дублировал декларацию бинов, прописывая их и в xml-e и через аннотации (ну так Дабы наверно).

А где же находится правда? Неужто как неизменно посередине?
Давайте испробуем разобраться…

Для начала давайте сравним стратегии декларации бинов.

Начнём с классического XML-a:

<beans....>
 <bean id="coolDao"/>

    <bean id ="coolService" 
                             init-method="init" 
                             destroy-method="closeResources"
                             scope="prototype">
           <property name="dao" ref="coolDao"/>
    </bean>

</beans>
Сейчас тоже самое, но при помощи аннотаций:
@Repository
public class CoolDaoImpl implements CoolDao {
    @Override
    public void doCRUD() {
        //some logic here
    }
}

@Service
@Scope(BeanDefinition.SCOPE_PROTOTYPE)
public class CoolServiceImpl implements CoolService {
    @Autowired
    private CoolDao dao;

    @PostConstruct
    public void init() {
        //init logic here
    }

    @PreDestroy
    public void closeResources() {
        //close resources here
    }

    @Override
    public void doWork() {
        dao.doCRUD();       
    }
}

Ещё разок, но с конфигурацией на джаве:
@Configuration
public class JavaConfig {
    @Bean
    public CoolDao dao(){
        return new CoolDaoImpl();
    }

    @Bean(initMethod = "init", destroyMethod = "closeResources")
    @Scope(BeanDefinition.SCOPE_PROTOTYPE)
    public CoolService coolService(){
        CoolServiceImpl service = new CoolServiceImpl();
        service.setDao(dao());
        return service;
    }
}

И наконец тоже самое на груви:
beans {
    coolDao(CoolDaoImpl)

    coolService(CoolService){bean->
        bean.scope = 'prototype'
        bean.initMethod = 'init'
        bean.destroyMethod = 'closeResources'
    }
}

Если сопоставлять затраченные усилия, то для данной конфигурации главенствуют аннотации (их каждого 6 штук, минус сеттер).
Но от того что конфигурация полновесного приложения (а не отдельного модуля), включающее также сторонние библиотеки, не может держаться только на аннотациях, было бы больше Добросовестно сопоставлять между конфигурациями Groovy, Java и XML. Даже без очков видно, что конфигурация на груви главенствует по лаконичности и элегантности, впрочем мне хотелось бы оставить её на закуску. Тем больше, что она пока ещё не допилена до конца.

А пока давайте обсудим недочеты и превосходства того, что было до выходпрописанные в XML-e либо при помощи аннотаций, будут создаваться именно с его поддержкой. Если все они синглтоны, то это не так значимо: легко немножко увеличится время бутсрапа. Впрочем, если ваша программа непрерывно создаёт прототайпы, Reflection не желанен. Ну а с конфигурацией на Java, рефшекшон легко не применяется. Бины создаются обыкновенным Java-кодом.

Превосходство аннотаций заключается в том, что они разрешают уменьшить конфигурацию. Помимо того, если всякий новейший бин, вынуждает разработчика бегать в конфиг, и что-то там править либо дописывать, то помимо неудобства и непрерывных мёрджей, появляется вероятность, того, что кто-то нечаянно испортит чужое. Помимо того, как мы восхитительно знаем, если в первом акте на сцене висит ружьё…

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

Кто-то скажет, мол, а вот мы не пользуемся аннотациями вообще: да это не неизменно комфортно, но все централизовано. Ну здесь одно из 2-х, либо ваш план дюже небольшой, и спринга в нём кот наплакал, либо каждая эта «централизованность», не вносит ясности. Большие XML-ы либо Java-конфиги, разобраться в которых может только гроссмейстер по шахматам, в результате приводят к ещё большей путанице.

Результаты

Все наши классы, которые обязаны являться бинами Спринга, объявляются и настраиваются аннотациями, прекрасно раскладываются по пэкэджам и сканируются, по указанию центральной конфигурации.
Все бины из сторонних библиотек, и то, что нуждается в трудной конфигурации определяется в Java config.
А та часть конфигурации, которая нуждается в динамизме выносится в XML, тот, что, вдобавок дозволено еще и беречь, как внешний источник.

Для чего же необходимо было придумывать конфигурацию на Groovy, когда и без нее теснее хватало бедлама? Груви, безусловно сегодня в моде, но разве это повод добавлять ещё одну конфигурацию, увеличивая путаницу? Давайте разберемся в чем его суть?

Конфиг на Groovy

Идея Groovy-конфигурации заключается в том, Дабы заменить всё, помимо аннотаций. Она владеет всеми плюсами XML – чай это скрипт, и его так же дозволено удерживать как внешний источник. Больше того динамизму может быть еще огромнее, в потенциале, метаморфозы конфигурации не будут требовать рестарта.
С иной стороны, она владеет и всеми плюсами Java-конфига, и больше того, код на груви, лаконичней, изящней и мощнее.
Правда, на данном этапе, его еще невозможно в полной мере применять взамен Java-конфигурации, потому что отсутствует помощь namespac’ов а ля @EnableAspectJAutoProxy, @EnableAsync и многое другое. Это, безусловно, дозволено решить, настроив все надобные бины в конфигурации, но Дабы не заморачиваться, проще пока оставить Java-конфиг. А вот XML теснее дозволено выкидывать :)

Ощущая, как от последней фразы сжались кулаки у последователей XML-а, я предлагаю устроить батл.
В синий угол ринга приглашаются все оптимисты, которые не опасаются новых спецтехнологий, а напротив пытаются их внедрять, Дабы двигаться вперед самим и двигать свою компанию. Они будут сражаться за наивысший динамизм, за вероятность девелоперов делать огромнее и проще, за Agile-разработку и за технические инновации.
В алый угол ринга приглашаются обученные горьким навыком реалисты, которые знают, что произойдёт, когда у всех появится сила. Эти люди сегодня, ценят то, что конфигурация на джаве – Type Safe, а XML не даёт никому вероятность наломать дров.

Ну а пока батл продолжается, я рискну высказать своё предположение, чем закончится война вопреки XML-ов. Давайте ещё раз посмотрим на картинку и припомним, ветхий фильм:

Шварценеггер, безусловно, в результате поборол, но какой ценой…

Ну а если кто захочет продолжить баттл в живую, приходите на мой отчет: Spring the Ripper, кто хочет серьёзно поднять свои навыки — приходите на тренинг Spring for Seniors

Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB