Google Guice vs. PicoContainer для введення залежностей

Моя команда досліджує рамки ін'єкцій залежностей і намагається вирішити між використанням Google-Guice та PicoContainer.

Ми шукаємо декілька речей у наших рамках:

1. Невеликий слід коду - Що я маю на увазі під невеликим кодовим відбитком, це те, що ми не хочемо мати код сміття для введення залежності скрізь у нашій кодовій базі. Якщо нам потрібно зробити рефактор по дорозі, ми хочемо, щоб це було якомога легше.
2. Продуктивність - скільки накладних витрат має кожен фреймворк при створенні та введенні об'єктів?
3. Простота використання - чи існує велика крива навчання? Чи потрібно писати кургани коду, щоб отримати щось просте? Ми хочемо мати якомога менше конфігурації.
4. Розмір спільноти - Більші громади зазвичай означають, що проект буде надалі підтримуватися. Ми не хочемо використовувати фреймворк та мусимо виправляти власні помилки;) Також на будь-які запитання, які виникають у нас на цьому шляху, можна (сподіваємось) відповісти розробником / користувачем рамки.

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

Відмова: Я досить новачок в ін'єкційній залежності, тому вибачте, що я задав питання, яке не стосується цієї дискусії.

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

З'єднання з рамкою

Pico - Pico прагне відмовити ін’єкцій сетерів, окрім іншого, вашим класам не потрібно знати про Pico. Потрібно знати лише проводку (справедливо для всіх рам DI).

Guice - Guice тепер підтримує стандартні анотації JSR 330 , тому конкретні примітки для Guice вам більше не потрібні. Весна також підтримує ці стандартні примітки. Аргумент, який використовують хлопці Guice, полягає в тому, що без запущеного процесора анотації Guice це не повинно впливати, якщо ви вирішите використовувати інший фреймворк.

Весна - Весна має на меті дозволити вам уникнути будь-якої згадки про весняний фреймворк у своєму коді. Оскільки у них є багато інших помічників / утиліт тощо. Спокуса досить сильна, щоб залежати від Spring коду.

Продуктивність

Піко - я не надто знайомий зі швидкісними характеристиками Піко

Guice - Guice був розроблений таким чином, щоб він був швидким, а порівняння, згадане в посиланні, має деякі цифри. Безумовно, якщо швидкість є першочерговою увагою або за допомогою Guice, або за допомогою електропроводки вручну

Весна - Весна може бути повільною. Була проведена робота з її швидшого використання, а використання бібліотеки JavaConfig повинно прискорити роботу.

Простота використання

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

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

Spring - відносно простий у налаштуванні, але більшість прикладів використовують Spring XML як метод конфігурації. Весняні XML-файли з часом можуть стати дуже великими та складними та потребують часу для завантаження. Подумайте про використання суміші пружинного та ручного колінчастого впорскування для подолання цього.

Розмір спільноти

Піко - малий

Guice - середній

Весна - велика

Досвід

Піко - Я не мав великого досвіду роботи з Pico, але це не є широко використовуваною основою, тому буде складніше знайти ресурси.

Guice - Guice - це популярна основа, і її спрямованість на швидкість вітається, коли у вас є великий проект, який ви перезапускаєте багато в розробці. У мене є стурбованість розподіленим характером конфігурації, тобто не просто зрозуміти, як складається вся наша програма. У цьому відношенні це трохи схоже на АОП.

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

Список літератури

• Піко
• Guice
• Весна
• Порівняння весни / Guice / Pico
• Ще одне порівняння продуктивності Spring / Guice

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

Єдиною реальною перевагою весни є розмір громади (і, чесно кажучи, зважаючи на розмір та складність, це потрібно), проте Піко та Гіс не потребують величезної спільноти, оскільки їх рішення набагато чистіше, організованіше та елегантніше. Pico здається більш гнучким, ніж Guice (ви можете використовувати анотації в Pico, чи ні - це надзвичайно ефективно). (Редагувати: Хочеться сказати, що вона надзвичайно гнучка, не те, що вона також не є ефективною.)

Крихітний розмір Піко і відсутність залежностей - ОСНОВНА перемога, яку не слід занижувати. Скільки мегів вам потрібно завантажити, щоб використовувати Spring зараз? Це безладдя з величезних файлів jar, з усіма залежностями. Інтуїтивно роздумуючи, таке ефективне і «маленьке» рішення повинно масштабуватись та працювати краще, ніж щось на зразок Весна. Чи справді весняне цвітіння покращить масштаб? Це дивний світ? Я б не припускав, що Весна є "більш масштабованою", поки це не доведено (і не пояснено).

Іноді створювати щось хороше (Pico / Guice), а потім утримувати свої ВИМКНЕННЯ від цього замість того, щоб додавати функції розмиву та кухонної мийки з нескінченними новими версіями, справді виходить ...

ПРИМІТКА. Це скоріше коментар / бурхливість, ніж відповідь

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 починає розквітати, подібно до того, як Весна поверталася в перші дні.

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

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

Якщо ви користуєтеся мінімалістичним контейнером DI, ви можете перевірити перо . Ванільний JSR-330 DI функціональний, але досить хороший з точки зору сліду (16 КК, відсутність залежностей) та продуктивності. Працює на андроїд.

Хоча мені подобається PicoContainer за її простоту і відсутність залежностей. Я б рекомендував використовувати натомість CDI, оскільки він є частиною стандарту Java EE, тому у вас немає блокування постачальника.

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

Легкий контейнер CDI, який я використовую для власних проектів, - це Apache Open Web Beans. Хоча знадобилося певний час, щоб розібратися, як створити простий додаток (на відміну від Піко), який виглядає приблизно так.

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();
}