Google Guice против 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

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

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

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

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

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

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

• Weld / CDI

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

• Guice / весна

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

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

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

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

Answer 5

Другим отличием является то, что 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 6

Я использовал Guice в безсерверном приложении AWS Lambda. AWS рекомендует использовать Guice или Dagger over Spring в лямбда-функции. См. Рекомендации AWS Lambda

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

Хотя в OP не упоминается Spring, Spring и CDI / weld предназначены для приложений уровня предприятия, которым часто требуются дополнительные функции, предоставляемые этими платформами. Следовательно, для небольших приложений, в которых требуется только DI, оптимальным является Guice или Dagger.