Google Guice vs. JSR-299 CDI/Weld

Question

Weld, JSR-299 Контексты и внедрение зависимостей инъекций, рассматривает себя как своего рода преемник Spring и Guice.

На CDI повлияло множество существующих Java-фреймворков, включая Seam, Guice и Spring. Тем не менее, у CDI свой собственный, очень отличный характер: более типичный, чем Seam, более сдержанный и менее ориентированный на XML, чем Spring, больше веб-приложений и корпоративных приложений, чем Guice. Но это не могло быть ни одним из них без вдохновения из упомянутых рамок и большого сотрудничества и напряженной работы Экспертной группы JSR-299 (EG).

http://docs.jboss.org/weld/reference/latest/en-US/html/1.html

Что делает Weld более способным для корпоративных приложений по сравнению с Guice? Существуют ли какие-либо преимущества или недостатки по сравнению с Guice? Что вы думаете о Guice AOP по сравнению с перехватчиками Weld? Как насчет производительности?

Мой выбор

В конце концов, я решил использовать Guice, потому что мне нравится модель чистого программирования, который поставляется почти без аннотации, кроме @Inject по умолчанию. Гораздо проще использовать внешние библиотеки с Guice, чем с CDI. AOP также довольно проста с Guice.

Answer 1

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

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

Answer 2

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

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

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

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

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

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

• Weld/CDI

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

• Guice/Spring

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

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

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

Performance

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

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

Answer 3

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

Т.е. Аннотируя компонент с @Named("book"), компонент становится известным в объединенном EL (язык выражений) как «book».

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

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

Answer 4

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

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

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

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

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

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

Answer 5

CDI for Guice users хорошее сравнение.