Google Guice vs. PicoContainer for Dependency Injection

100

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.

austen
źródło
Aktualizacja: możesz również rozważyć CDI 2.0 - Contexts & Dependency Injection for Java . Standaryzowany w JSR 365 od 2017-04.
Basil Bourque

Odpowiedzi:

115

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

Jamie McCrindle
źródło
1
To, czego nauczyłem się (od kogoś innego, a nie z używania go samodzielnie), to to, że PicoContainer jest lżejszy niż Guice. Ponadto, patrząc na dokument PicoContainer, wydaje się, że jest on prostszy w użyciu. Wyszuka zależności w samych konstruktorach i nie musisz określać, którego konstruktora użyć. Po prostu używa pasującego.
Kissaki
2
Tak, teraz jestem wielkim fanem PicoContainer. To takie „proste”, ale działające rozwiązanie, nie mogę nie patrzeć na Spring jako nadęty i przestarzały w dzisiejszych czasach. Guice jest również fajny (i ma dobrego sponsora w Google), ale uważam, że Pico ma również więcej funkcji / elastyczności, będąc starszym. Dobrze jest zobaczyć fajne alternatywy dla okropnej konfiguracji XML!
Manius
Odnosząc się do powyższego opisu „nie powszechnie używanego” Pico, prawdą jest, że nie jest tak popularny jak inne, ale biorąc pod uwagę, że jest mniejszy / prostszy niż inne rozwiązania, znacznie mniej prawdopodobne jest, że napotkasz nietypowe problemy. Jeśli tak, to jest ładna i bardzo responsywna lista mailingowa. Pico jest również nieinwazyjne (chyba że zdecydujesz się użyć adnotacji, to opcja), nie potrzebujesz adnotacji typu Guice, co oznacza mniej pracy przy okablowaniu kodu wtrysku. (tak, jestem stronniczy, ale Pico jest po prostu fajny) Guice jest z pewnością dobrym narzędziem DI (lepszym niż Spring IMO).
Manius
1
Używam Pico w wielu bardzo dużych (i intensywnych) projektach (setki typów komponentów zdefiniowanych w każdym kontenerze) i korzystałem z większości jego różnych funkcji i nie mogłem być z nim szczęśliwszy.
jhouse
2
Właśnie wykonałem prosty test wydajności z Guice / Spring / PicoContainer - Guice i PicoContainer są dość podobne. W niektórych przypadkach Guice był trochę szybszy. We wszystkich przypadkach wiosna była bardzo powolna.
Joshua Davis,
25

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 ...

Manius
źródło
1
Chcesz powiedzieć, dlaczego Pico i Guice są lepsi od Spring?
Thorbjørn Ravn Andersen
4
Myślałem, że tak - w zasadzie robią DI równie dobrze, są prostsze / mniejsze / czystsze i nie mają żadnych zależności lub mają kilka zależności. Nie oznacza to, że wiosna nigdy nie ma sensu (jestem pewien, że są przypadki), mówię tylko, że prostsze jest lepsze, jeśli twoje wymagania są spełnione. W przypadku bardzo dużej liczby projektów wystarczy niewielka biblioteka obsługi.
Manius
12

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!

Joshua Davis
źródło
Ale strona codehaus wciąż się zawiesiła i nie ma informacji o jakimkolwiek ruchu. Myślałem, że Pico nie żyje;)
Vladislav Rastrusny
1
Jeśli strona nie jest aktualna z kodem, może to wskazywać, że projekt spadł poniżej masy krytycznej.
Thorbjørn Ravn Andersen
@ ThorbjørnRavnAndersen Yes. Niestety myślę, że Pico został zastąpiony przez Guice'a i CDI.
Joshua Davis,
5
Od 8 marca 2013 r. Witryna picocontainer.org wydaje się być zajęta przez squattera domeny. Wydaje się, że witryna picocontainer.com jest obecnie kanoniczną witryną.
dOxxx
2

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.

ACAndreani
źródło
Lubię Daggera, ale wygląda na to, że w publicznych repozytoriach nie ma jeszcze wtyczki Gradle dla projektów innych niż Android (tj. Wtyczki Gradle do „zwykłych” projektów java). Rozważyłbym to w przypadku projektów Java, gdyby w publicznych repozytoriach była wtyczka.
Joshua Davis
2

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.

Cellux
źródło
Hej, Feather jest niesamowity! Użyłem go do zaimplementowania wtyczki DI dla ActFramework . Zrobiłem kilka aktualizacji, np. Automatycznie wywołaj injectFields w razie potrzeby i wsparcie dla słuchacza wtrysku, daj mi znać, jeśli chcesz, żebym odesłał żądanie pull
Gelin Luo
@green Widzę, że przeniosłeś się do Genie. Czy mógłbyś podzielić się swoimi doświadczeniami związanymi z używaniem Feather?
piwoBear
1
Pióro @beerBear jest bardzo lekkie i bardzo łatwe w użyciu w większości przypadków użycia DI. Ponieważ jednak pracuję na pełnym frameworku MVC, potrzebuję rozwiązania, które implementuje pełną specyfikację JSR330. Dlatego przeniosłem się do Genie
Gelin Luo
@green Doceniam twój post z wyjaśnieniem, aby uzyskać lepsze zrozumienie.
piwoBear
0

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();
}
Archimedes Trajano
źródło
2
Jeśli pozostaniesz przy JSR-330 w kodzie swojej biblioteki, możesz ograniczyć kod kontenera do minimum.
Thorbjørn Ravn Andersen
Nadal potrzebujesz kodu kontenera w testach automatycznych. Chociaż nie oznacza to, że w swoim rzeczywistym kodzie miałbyś kod specyficzny dla kontenera (a i tak nie powinieneś, chyba że planujesz uruchomić własny „main”, który w jednej aplikacji, którą napisałem dla siebie, zrobiłem.
Archimedes Trajano