Google Guice против PicoContainer для внедрения зависимостей

100

Моя команда изучает фреймворки внедрения зависимостей и пытается выбрать между использованием Google-Guice и PicoContainer.

В нашем фреймворке мы ищем несколько вещей:

  1. Небольшой след кода. Под небольшим размером кода я подразумеваю, что мы не хотим, чтобы повсюду в нашей базе кода был мусор кода внедрения зависимостей. Если нам понадобится провести рефакторинг в будущем, мы хотим, чтобы это было как можно проще.
  2. Производительность - сколько накладных расходов возникает у каждой структуры при создании и внедрении объектов?
  3. Простота использования - нужно ли много учиться? Нужно ли писать кучу кода, чтобы что-то простое работало? Мы хотим иметь как можно меньше настроек.
  4. Размер сообщества - более крупные сообщества обычно означают, что проект будет продолжать поддерживаться. Мы не хотим использовать фреймворк и должны исправлять наши собственные ошибки;) Также на любые возникающие у нас вопросы (надеюсь) ответит сообщество разработчиков / пользователей фреймворка.

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

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

Остин
источник
Обновление: вы также можете рассмотреть CDI 2.0 - Contexts & Dependency Injection для Java . Стандартизировано в JSR 365 с 2017-04.
Basil

Ответы:

115

Вы можете включить Spring в свой список рассматриваемых вами фреймворков для внедрения зависимостей. Вот несколько ответов на ваши вопросы:

Крепление к каркасу

Пико - Пико имеет тенденцию препятствовать внедрению сеттера, но кроме этого, вашим классам не нужно знать о Пико. Это нужно знать только проводке (верно для всех фреймворков DI).

Guice - Guice теперь поддерживает стандартные аннотации JSR 330 , поэтому вам больше не нужны специальные аннотации Guice в вашем коде. Spring также поддерживает эти стандартные аннотации. Аргумент, который используют ребята из Guice, заключается в том, что без запущенного процессора аннотаций Guice это не должно повлиять, если вы решите использовать другую структуру.

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

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

Пико - я не слишком знаком со скоростными характеристиками Пико

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

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

Легкость использования

Pico - прост в настройке. Pico может принять за вас несколько решений по автоподводке. Непонятно, как это масштабируется для очень больших проектов.

Guice - просто настроить, вы просто добавляете аннотации и наследуете от AbstractModule, чтобы связать вещи вместе. Хорошо масштабируется для крупных проектов, поскольку конфигурация сведена к минимуму.

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

Размер сообщества

Пико - Маленький

Guice - средний

Весна - большая

Опыт

Pico - у меня не было большого опыта работы с Pico, но это не широко используемый фреймворк, поэтому найти ресурсы будет сложнее.

Guice - Guice - популярный фреймворк, и его ориентация на скорость приветствуется, когда у вас есть большой проект, который вы часто перезапускаете в разработке. Меня беспокоит распределенный характер конфигурации, то есть непросто увидеть, как все наше приложение устроено вместе. В этом отношении это немного похоже на АОП.

Весна - Обычно я выбираю весну по умолчанию. Тем не менее, XML может стать громоздким и, как следствие, раздражать замедление. Я часто использую комбинацию вручную созданного внедрения зависимостей и Spring. Когда вам действительно нужна конфигурация на основе XML, Spring XML вполне подойдет. Spring также приложил много усилий, чтобы сделать другие фреймворки более дружественными к внедрению зависимостей, что может быть полезно, потому что они часто используют лучшие практики при этом (JMS, ORM, OXM, MVC и т. Д.).

Ссылки

Джейми МакКриндл
источник
1
Я узнал (от кого-то другого, а не от самого себя), что PicoContainer легче, чем Guice. Кроме того, если посмотреть на документ PicoContainer, он также кажется более простым в использовании. Он будет искать зависимости в самих конструкторах, и вам не нужно указывать, какой конструктор использовать. Он просто использует подходящий.
Киссаки
2
Да, я сам сейчас большой поклонник PicoContainer. Это просто такое «простое», но рабочее решение, я не могу не смотреть на Spring как на раздутый и устаревший в наши дни. Guice тоже хорош (и у него есть хорошая поддержка со стороны Google), но я считаю, что Pico также имеет больше возможностей / гибкости, будучи старше. Приятно видеть хорошие альтернативы неприятной конфигурации xml!
Manius
Что касается приведенного выше описания Pico «не широко используется», это правда, что он не так популярен, как другие, но, учитывая, что он меньше / проще, чем другие решения, у вас гораздо меньше шансов столкнуться с необычными проблемами. Если вы это сделаете, есть хороший и очень отзывчивый список рассылки. Кроме того, Pico не является инвазивным (если вы не решите использовать аннотации, это вариант), вам не нужны аннотации, такие как Guice, что означает меньше работы по настройке кода инъекции. (да, я предвзят, но Pico такой крутой) Guice, безусловно, хороший инструмент DI (лучше, чем Spring IMO).
Manius
1
Я использую pico в ряде очень больших (и интенсивно используемых) проектов (сотни типов компонентов, определенных в каждом контейнере), и использовал почти все его различные функции, и очень доволен этим.
jhouse 02
2
Я только что сделал простой тест производительности с Guice / Spring / PicoContainer - Guice и PicoContainer довольно похожи. В некоторых случаях Guice был немного быстрее. Весна во всех случаях была очень медленной.
Джошуа Дэвис
25

Ответ jamie.mccrindle на самом деле довольно хорош, но я не понимаю, почему Spring является выбором по умолчанию, когда совершенно очевидно, что доступны превосходные альтернативы (как Pico, так и Guice). Популярность IMO Spring достигла своего пика, и теперь она в настоящее время живет за счет генерируемой шумихи (вместе со всеми другими подпроектами Spring «я тоже», стремящимися оседлать подножку Spring).

Единственное реальное преимущество Spring - это размер сообщества (и, откровенно говоря, из-за размера и сложности это необходимо), но Pico и Guice не нуждаются в огромном сообществе, потому что их решение намного чище, организованнее и элегантнее. Pico кажется более гибким, чем Guice (вы можете использовать аннотации в Pico или нет - это чрезвычайно эффективно). (Изменить: имелось в виду, что он чрезвычайно гибкий, а не то, что он неэффективен.)

Крошечный размер Pico и отсутствие зависимостей - ГЛАВНАЯ победа, которую нельзя недооценивать. Сколько мегабайт вам нужно скачать, чтобы использовать Spring сейчас? Это беспорядок огромных файлов jar со всеми их зависимостями. При интуитивном мышлении такое эффективное и «маленькое» решение должно масштабироваться и работать лучше, чем что-то вроде Spring. Действительно ли раздувание Spring улучшит масштабирование? Это причудливый мир? Я бы не стал делать предположений, что Spring «более масштабируем», пока это не будет доказано (и объяснено).

Иногда создать что-то хорошее (Pico / Guice), а затем держать руки в стороне от этого вместо добавления функций раздувания и кухонной раковины с бесконечными новыми версиями, действительно работает ...

Manius
источник
1
Хотите сказать, почему Пико и Гайс лучше Spring?
Thorbjørn Ravn Andersen
4
Я думал, что это так - в основном, они также делают DI, они проще / меньше / чище, и у них нет или мало зависимостей. Это не значит, что Spring никогда не имеет смысла (я уверен, что есть случаи), все, что я говорю, это то, что чем проще, тем лучше, если ваши требования выполняются. А для очень большого количества проектов все, что вам нужно, - это небольшие библиотеки поддержки.
Маниус
12

ПРИМЕЧАНИЕ: это больше комментарий / напыщенная речь, чем ответ

ПикоКонтейнер великолепен. Я бы вернулся к нему, если бы они просто исправили свои веб-сайты. Это действительно сбивает с толку:

  • http://picocontainer.com, который является самым последним, но многие страницы имеют проблемы с форматированием, а некоторые страницы вообще не работают. Похоже, страницы были автоматически преобразованы из старого контента.
  • http://picocontainer.codehaus.org/ Что кажется застывшим во времени в версии 2.10.2. Было бы очень хорошо, если бы на страницах было написано что-то вроде "эй, вы смотрите на старый веб-сайт!"
  • http://docs.codehaus.org/display/PICO/Home - Вики-сайт слияния, который документирует версию 1.x, но нигде на страницах не говорит об этом!

Сейчас я использую Guice 2.x, хотя он больше и имеет меньше функций. Просто найти документацию было намного проще, а группа пользователей очень активна. Однако, если направление Guice 3 является каким-либо признаком, похоже, что Guice начинает раздуваться, как и Spring в свое время.

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

Джошуа Дэвис
источник
Но сайт codehaus по-прежнему заморожен, и информации о каком-либо движении нет. Я думал, Пико мертв;)
Владислав Раструсный 04
1
Если веб-сайт не обновлен с кодом, это может быть признаком того, что проект упал ниже критической массы.
Торбьорн Равн Андерсен
@ ThorbjørnRavnAndersen Да. К сожалению, я думаю, что Пико уступили Guice и CDI.
Джошуа Дэвис
5
По состоянию на 8 марта 2013 года сайт picocontainer.org, похоже, занят самозванцем. picocontainer.com теперь кажется каноническим сайтом.
dOxxx 08
2

Это старый вопрос, но сегодня вы можете рассмотреть Dagger ( https://github.com/square/dagger ) в своем проекте Android-приложения. Dagger генерирует код во время компиляции. Таким образом, вы получаете более короткое время запуска и меньшее использование памяти во время выполнения.

ACAndreani
источник
Мне нравится Dagger, но похоже, что в публичных репозиториях нет плагина Gradle для проектов, отличных от Android (т.е. плагина Gradle для «обычных» java-проектов). Я бы рассмотрел это для проектов Java, если бы в общедоступных репозиториях был плагин.
Джошуа Дэвис
2

Если вам нужен минималистичный контейнер DI, вы можете попробовать Feather . Ванильная JSR-330 только функциональность DI, но неплохая с точки зрения занимаемой площади (16 КБ, без зависимостей) и производительности. Работает на android.

Cellux
источник
Эй, Перо классное! Я использовал его для реализации плагина DI для ActFramework . Я сделал несколько обновлений, например, автоматический вызов injectFields, если необходимо, и поддержку прослушивателя инъекций, дайте мне знать, если вы хотите, чтобы я отправил обратно запрос на
перенос
@green Я вижу, вы перешли в Genie. Не могли бы вы поделиться своим опытом использования Feather?
beerBear 01
1
@beerBear Feather очень легкий и очень простой в использовании в большинстве случаев использования DI. Однако, поскольку я работаю над полнофункциональной платформой MVC, мне нужно решение, реализующее полную спецификацию JSR330. Вот почему я перешел в Genie
Gelin Luo
@green Я ценю ваш пост с объяснением, чтобы лучше понять.
beerBear
0

Хотя мне нравится PicoContainer за его простоту и отсутствие зависимостей. Я бы рекомендовал вместо этого использовать CDI, потому что он является частью стандарта Java EE, поэтому у вас нет привязки к поставщику.

С точки зрения навязчивости, основная проблема - это требование контейнера и использование относительно пустого файла META-INF / beans.xml (необходимого, чтобы указать, что jar использует CDI) и использование аннотаций (хотя они стандартные )

Легкий контейнер CDI, который я использую для своих собственных проектов, - это Apache Open Web Beans. Хотя потребовалось время, чтобы понять, как создать простое приложение (в отличие от Pico), которое выглядит так.

public static void main(final String[] args) {
    final ContainerLifecycle lifecycle = WebBeansContext.currentInstance()
            .getService(ContainerLifecycle.class);
    lifecycle.startApplication(null);

    final BeanManager beanManager = lifecycle.getBeanManager();
    // replace Tester with your start up class
    final Bean<?> bean = beanManager.getBeans(Tester.class).iterator()
            .next();

    final Tester b = (Tester) lifecycle.getBeanManager().getReference(bean,
            Tester.class, beanManager.createCreationalContext(bean));
    b.doInit();
}
Архимед Траяно
источник
2
Если вы придерживаетесь JSR-330 в коде своей библиотеки, вы можете свести к минимуму код, специфичный для контейнера.
Thorbjørn Ravn Andersen
При автоматическом тестировании вам по-прежнему нужен код, специфичный для контейнера. Хотя это не означает, что у вас будет конкретный для контейнера код в вашем фактическом коде (и вам не следует этого делать, если вы не планируете запускать свой собственный «main», который я и сделал в одном приложении, которое я написал для себя.
Архимед Траджано