Google Guice против JSR-299 CDI/Weld

Ответ 1

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

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

Возможности предприятия в Weld

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

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

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

• приварку/КДИ

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

• Guice/ Spring

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

AOP и перехватчики

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

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

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

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

Ответ 2

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

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

Ответ 3

Самая важная особенность CDI противоречит Guice, заключается в том, что она является стандартной частью Java EE 6.

Значение этого нельзя недооценивать, так как это означает, что CDI является стандартом DI, который вы должны использовать при кодировании веб-приложений.

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

Оказалось, что лучший способ сделать это для базы кода, используемой как в настольных, так и в веб-приложениях, - использовать аннотации JSR-330 для нашего кода, а затем использовать либо CDI, либо Guice (SVN, скоро в 3.0) в качестве двигателя.

После нескольких проектов я обнаружил, что лучше всего использовать конфигурацию Guice вместо непрозрачной магии, происходящей в Weld. Кроме того, я обнаружил, что способ сделать то, что мы хотим, как описано выше с помощью Weld, я должен отметить класс в дополнительном банке как @Alternative, а затем упомянуть в beans.xml, что я хочу, чтобы альтернативный класс принудительно (и что не является надежным против рефакторинга).

Но, в целом, JSR-330 позволяет нам делать то, что было очень утомительно и хрупко раньше (потому что new так сильно связывается), и это отличная победа. Я могу настоятельно рекомендовать поиск DI, если у вас есть такая необходимость.

Ответ 4

CDI для пользователей Guice - хорошее сравнение.

Ответ 5

Другим отличием является то, что CDI очень ориентирован на Java EE. Он обеспечивает механизм склеить различные подсистемы Java EE.

Т.е. Аннотируя bean с @Named("book"), bean становится известным в унифицированном EL (язык выражений) как "book".

Затем вы можете использовать его на странице JSF, например:

    <h:outputLabel value="Book title:" for="bookTitle"/>
    <h:outputText id="bookTile" value="#{book.title}"/>