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

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

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

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

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

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

Вы можете включить 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 и т. Д.).

Ссылки

• Пико
• Guice
• весна
• Сравнение Spring / Guice / Pico
• Еще одно сравнение производительности Spring / Guice

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

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

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

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

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

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

• 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, и они внесли некоторые улучшения в веб-сайт. Теперь гораздо лучше!

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

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

Хотя мне нравится 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();
}