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

Question

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

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

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

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

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

Answer 1

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

Соединение с рамой

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

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

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

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

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

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

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

Удобство использования

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

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

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

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

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

Guice - Средний

пружина - большая

Опыт

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

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

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

Ссылки

• Pico
• Guice
• Весна
• Сравнение пружины / Guice / Pico
• Еще одно сравнение производительности Spring / Guice

Answer 2

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

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

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

Иногда создание чего-то хорошего (Pico / Guice) с последующим удалением РУК от него вместо добавления функций раздувания и кухонной мойки с бесконечными новыми версиями действительно работает ...

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

С точки зрения навязчивости, его главной проблемой является требование контейнера и использование относительно пустого файла META-INF / beans.xml (необходим для указания того, что в банке используется 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();
}