Google Guice vs. PicoContainer for Dependency Injection

Mój zespół bada frameworki wstrzykiwania zależności i próbuje zdecydować między używaniem Google-Guice a PicoContainer.

W naszym frameworku szukamy kilku rzeczy:

1. Mały ślad kodu - przez mały ślad kodu mam na myśli to, że nie chcemy, aby wszędzie w naszej bazie kodu zaśmiecał kod iniekcji zależności. Jeśli potrzebujemy refaktoryzacji w przyszłości, chcemy, aby było to tak łatwe, jak to tylko możliwe.
2. Wydajność - ile narzutów ma każda struktura podczas tworzenia i wstrzykiwania obiektów?
3. Łatwość obsługi - czy istnieje duża krzywa uczenia się? Czy musimy pisać mnóstwo kodu, aby coś prostego działało? Chcemy mieć jak najmniejszą konfigurację.
4. Wielkość społeczności - większe społeczności zwykle oznaczają, że projekt będzie kontynuowany. Nie chcemy używać frameworka i musimy naprawiać własne błędy;) Również na wszelkie pytania, które mamy po drodze, może (miejmy nadzieję) odpowiedzieć społeczność programistów / użytkowników frameworka.

Byłoby bardzo mile widziane porównanie obu ram z wymienionymi kryteriami. Wszelkie osobiste doświadczenia, które pomagają porównać te dwie rzeczy, byłyby również niezwykle pomocne.

Zastrzeżenie: Jestem całkiem nowy w iniekcji uzależnienia, więc wybacz moje nieudanie, jeśli zadałem pytanie, które nie dotyczy tej dyskusji.

Możesz dodać Spring do swojej listy frameworków Dependency Injection, które rozważasz. Oto kilka odpowiedzi na Twoje pytania:

Połączenie z ramą

Pico - Pico ma tendencję do zniechęcania do wstrzykiwania setera, ale poza tym twoje zajęcia nie muszą wiedzieć o Pico. Musi wiedzieć tylko okablowanie (prawda dla wszystkich frameworków DI).

Guice - Guice obsługuje teraz standardowe adnotacje JSR 330 , więc nie potrzebujesz już adnotacji specyficznych dla Guice w swoim kodzie. Spring obsługuje również te standardowe adnotacje. Argument, którego używają faceci z Guice, jest taki, że bez uruchomionego procesora adnotacji Guice nie powinny one mieć wpływu, jeśli zdecydujesz się użyć innego frameworka.

Spring - Spring ma na celu uniknięcie jakichkolwiek wzmianek o frameworku Spring w kodzie. Ponieważ mają wiele innych pomocników / narzędzi itp., Pokusa polegania na kodzie Spring jest jednak dość silna.

Występ

Pico - nie jestem zbyt zaznajomiony z charakterystyką szybkości Pico

Guice - Guice został zaprojektowany tak, aby był szybki, a porównanie wymienione w referencji ma kilka liczb. Z pewnością, jeśli szybkość jest głównym czynnikiem, należy rozważyć użycie Guice lub okablowania ręcznie

Wiosna - Wiosna może być powolna. Pracowano, aby było to szybsze, a użycie biblioteki JavaConfig powinno przyspieszyć działanie.

Łatwość użycia

Pico - prosty w konfiguracji. Pico może podjąć za Ciebie decyzje dotyczące autoprzewodów. Nie jest jasne, jak to skaluje się do bardzo dużych projektów.

Guice - Prosty w konfiguracji, wystarczy dodać adnotacje i dziedziczyć z AbstractModule, aby łączyć rzeczy ze sobą. Dobrze się skaluje do dużych projektów, ponieważ konfiguracja jest ograniczona do minimum.

Spring - stosunkowo łatwa w konfiguracji, ale większość przykładów używa Spring XML jako metody konfiguracji. Pliki Spring XML mogą z czasem stać się bardzo duże i złożone, a ich ładowanie może zająć trochę czasu. Aby temu zaradzić, rozważ użycie mieszanki Springa i ręcznego zastrzyku Dependency Injection.

Rozmiar społeczności

Pico - mały

Guice - średni

Wiosna - duża

Doświadczenie

Pico - nie miałem dużego doświadczenia z Pico, ale nie jest to powszechnie używany framework, więc trudniej będzie znaleźć zasoby.

Guice - Guice jest popularnym frameworkiem i skupienie się na szybkości jest mile widziane, gdy masz duży projekt, który często restartujesz w trakcie opracowywania. Martwię się rozproszonym charakterem konfiguracji, tzn. Nie jest łatwo zobaczyć, jak składa się cała nasza aplikacja. Pod tym względem jest trochę jak AOP.

Wiosna - Wiosna to zazwyczaj mój domyślny wybór. To powiedziawszy, XML może stać się uciążliwy, a wynikające z tego spowolnienie denerwujące. Często używam kombinacji ręcznie wykonanego Dependency Injection i Spring. Kiedy faktycznie potrzebujesz konfiguracji opartej na XML, Spring XML jest całkiem niezły. Spring włożył również wiele wysiłku w uczynienie innych frameworków bardziej przyjaznymi dla Dependency Injection, co może być przydatne, ponieważ często używają przy tym najlepszych praktyk (JMS, ORM, OXM, MVC itp.).

Bibliografia

• Pico
• Guice
• Wiosna
• Porównanie Spring / Guice / Pico
• Kolejne porównanie wydajności Spring / Guice

Odpowiedź udzielona przez jamie.mccrindle jest w rzeczywistości całkiem dobra, ale jestem zdezorientowany, dlaczego Spring jest domyślnym wyborem, skoro jest całkiem jasne, że dostępne są lepsze alternatywy (zarówno Pico, jak i Guice). Popularność IMO Spring osiągnęła swój szczyt i obecnie żyje z generowanego szumu (wraz ze wszystkimi innymi podprojektami wiosennymi „ja też”, które chcą podążać za modą Spring).

Jedyną prawdziwą zaletą Springa jest wielkość społeczności (i szczerze mówiąc, ze względu na rozmiar i złożoność, jest to potrzebne), ale Pico i Guice nie potrzebują ogromnej społeczności, ponieważ ich rozwiązanie jest znacznie czystsze, lepiej zorganizowane i eleganckie. Pico wydaje się bardziej elastyczny niż Guice (możesz używać adnotacji w Pico lub nie - jest to niezwykle wydajne). (Edycja: chcę powiedzieć, że jest niezwykle elastyczny, nie znaczy to, że nie jest również wydajny.)

Mały rozmiar Pico i brak zależności to DUŻA wygrana, której nie należy lekceważyć. Ile megabajtów musisz teraz pobrać, aby korzystać ze Springa? To nieznośny bałagan wielkich plików jar ze wszystkimi jego zależnościami. Myśląc intuicyjnie, takie wydajne i „małe” rozwiązanie powinno się skalować i działać lepiej niż coś takiego jak Spring. Czy wzdęcia wiosny naprawdę sprawią, że skalowanie będzie lepsze? Czy to dziwaczny świat? Nie zakładałbym, że Spring jest „bardziej skalowalny”, dopóki nie zostanie to udowodnione (i wyjaśnione).

Czasami tworzenie czegoś dobrego (Pico / Guice), a następnie trzymanie RĘCE ODRĘCZNEGO zamiast dodawania wzdęć i funkcji zlewu kuchennego z niekończącymi się nowymi wersjami, naprawdę się sprawdza ...

UWAGA: To bardziej komentarz / rant niż odpowiedź

PicoContainer jest świetny. Wróciłbym do tego, gdyby tylko naprawili swoje strony internetowe. Teraz jest to naprawdę zagmatwane:

• http://picocontainer.com, który jest najnowszy, ale wiele stron ma problemy z formatowaniem, a kilka stron w ogóle nie działa. Wygląda na to, że strony zostały automatycznie przekonwertowane ze starszej zawartości.
• http://picocontainer.codehaus.org/ Co w wersji 2.10.2 wydaje się zatrzymane w czasie - Byłoby naprawdę fajnie, gdyby na stronach było napisane coś w rodzaju „hej, przeglądasz starą witrynę internetową!”
• http://docs.codehaus.org/display/PICO/Home - Confluence wiki, która dokumentuje v 1.x, ale nie mówi tego nigdzie na stronach!

Używam teraz Guice 2.x, mimo że jest większy i ma mniej funkcji. Po prostu znacznie łatwiej było znaleźć dokumentację, a jej grupa użytkowników jest bardzo aktywna. Jeśli jednak kierunek Guice 3 jest jakąkolwiek wskazówką, wygląda na to, że Guice zaczyna się nadymać, tak jak wiosna robiła to dawno temu.

Aktualizacja: opublikowałem komentarz do ludzi z Pico Container i wprowadzili kilka ulepszeń na stronie internetowej. Teraz dużo lepiej!

To stare pytanie, ale dziś możesz rozważyć Dagger ( https://github.com/square/dagger ) w swoim projekcie aplikacji na Androida. Dagger generuje kod w czasie kompilacji. Dzięki temu uzyskujesz krótszy czas uruchamiania i mniejsze zużycie pamięci podczas wykonywania.

Jeśli szukasz minimalistycznego kontenera DI, możesz wypróbować Feather . Tylko funkcjonalność Vanilla JSR-330 DI, ale całkiem dobra pod względem zajmowanego miejsca (16K, bez zależności) i wydajności. Działa na Androidzie.

Chociaż lubię PicoContainer ze względu na jego prostotę i brak zależności. Poleciłbym zamiast tego używać CDI, ponieważ jest to część standardu Java EE, więc nie masz blokady dostawcy.

Jeśli chodzi o ingerencję, głównym problemem jest wymóg kontenera i użycie stosunkowo pustego pliku META-INF / beans.xml (potrzebnego do wskazania, że ​​słoik używa CDI) oraz użycie adnotacji (choć są one standardowe )

Lekki kontener CDI, którego używam do własnych projektów, to Apache Open Web Beans. Chociaż zajęło trochę czasu, aby dowiedzieć się, jak stworzyć prostą aplikację (w przeciwieństwie do Pico), która wygląda tak.

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