Google Guice по сравнению с CDI JSR-299 / сварка

CDI (Weld) пока не получил широкого распространения, поэтому сравнение провести сложно. Несколько моментов:

• CDI был разработан с учетом интеграции с EJB3, JSF и другими стандартами JavaEE. CDI имеет так называемые переносимые расширения, которые позволяют сторонним библиотекам интегрироваться с жизненным циклом, и внутреннее функционирование реализации CDI
• CDI был разработан с учетом всех возможных угловых случаев, поэтому вполне вероятно, что он охватывает все, что вам нужно. . Spring, Guice и Seam дошли до такого состояния, в то время как CDI использует опыт этих трех.
• На мой взгляд, перехватчики CDI не смогут удовлетворить все требования Spring AOP. Возможно, то же самое и с Guice AOP. Вы не можете определить перехватчик, используя синтаксис AspectJ.
• отсутствие определений xml является как преимуществом, так и недостатком, и некоторые люди (в некоторых случаях справедливо) предпочитают конфигурацию xml.
• расширенное использование аннотаций квалификаторов (на мой взгляд) приведет к большим беспорядкам, если их не использовать осторожно.

Прежде чем пытаться ответить на ваш вопрос, позвольте мне добавить важную информацию: JSR 330 ( @Inject ) был стандартизирован проектами Guice и Spring ( объявление от мая 2009 ) и повторно используется в JSR 299 . Это охватывает основные механизмы DI с точки зрения объявления точки впрыска.

Теперь вернемся к вопросу - с оговоркой, что у меня гораздо больше опыта работы со Spring, чем с Guice.

Корпоративные возможности в Weld

• Альтернативные механизмы конфигурации имеют очень чистый дизайн в JSR-299 и позволяют использовать механизмы конфигурации вне кода Java ( beans.xml ).
• События - очень мощная вещь, которая прекрасно сочетается с JMS. Я только что нашел шину событий для Guice , но не могу сказать, как это можно сравнить.
• Переносимые расширения - это SPI, который можно использовать для интеграции с существующей технологией или для простой оболочки унаследованного кода.

Преимущества / недостатки

Примечание: я попытаюсь добавить сюда несколько пунктов позже, но этот ответ уже длиннее, чем я ожидал, извините.

• Weld / CDI

  • Стандартизация : Если что-то стандартизировано и есть хорошая реализация, многие люди будут это использовать.Пример: Встроенные области видимости в Weld предоставляют несколько больше областей, чем Guice или Spring . Все они могут быть расширены, но фреймворки приложений будут скорее полагаться на стандартные области, если они используются большим сообществом.
  • Поддержка контейнера : аналогично предыдущему пункту, но является основным аргументом в пользу принятия. Основные серверы приложений с открытым исходным кодом, такие как Glassfish и JBoss 6, предоставляют поддержку CDI (см. здесь ).

• Guice / Spring

  • Фактическое приложение : Большинство существующих приложений уже используют Guice / Spring. Spring / Guice всегда основывались на стандартах и ​​предоставляли новые возможности там, где стандартов не существовало или их нельзя было использовать. Если вы будете следовать соответствующим передовым методикам, фреймворк поможет вам сделать ваше приложение чистым и основанным на стандартах.

АОП и перехватчики

Это очень активно обсуждаемая тема, и я не могу отдавать предпочтение одному перед другим. Оба механизма очень мощные, но требуют хотя бы минимального понимания архитектуры приложения. Также посмотрите Декораторы и ранее упомянутые События . Лучше всего использовать правильный инструмент, но не забывайте, что если разработчик должен работать с одним из этих механизмов, хорошо, если он / она понимает концепцию.

Производительность

К сожалению, я пока не смог разобраться в этом, но есть несколько правил, которым я стараюсь следовать, особенно при использовании фреймворка, который дает вам много функций, а вы этого не замечаете:

• По возможности, предпочитайте один шаг подключения нескольким поискам во время выполнения.
• Если возможно, выполните все подключения при инициализации приложения.
• Любой шаг перехвата или прокси-сервер AOP добавляют в стек несколько вызовов методов.