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

Ответ 1

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

Связь с каркасом

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

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

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

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

Pico. Я не слишком хорошо знаком с характеристиками скорости Pico

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

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

Простота использования

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

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

Spring. Относительно легко настроить, но большинство примеров используют Spring XML в качестве метода конфигурации. Spring XML файлы могут стать очень большими и сложными с течением времени и требуют времени для загрузки. Подумайте о том, чтобы использовать смесь Spring и ручную зависающую инъекцию для преодоления этого.

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

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

Guice - средний

Spring - Большой

Опыт

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

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

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

Ссылки

• Pico
• Guice
• Spring
• Spring/Сравнение Guice/Pico
• Другое сравнение производительности Spring/Guice

Ответ 2

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

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

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

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

Ответ 3

ПРИМЕЧАНИЕ. Это скорее комментарий /rant, чем ответ

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 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();
}