Dlaczego warto używać CDI w Java EE

Wiem, że jest wiele artykułów, które wyjaśniają, jak używać CDI w Java EE, ale mam problem z zorientowaniem się, jakie korzyści to przynosi. Załóżmy na przykład, że mam klasę, która obecnie używa instancji Foo. I might either do 

Foo myFoo = new Foo();

Lub 

// Better, FooFactory might return a mock object for testing    
Foo myFoo = FooFactory.getFoo();

Czytam to z CDI mogę zrobić: 

@Inject
Foo myFoo;

Ale dlaczego jest to lepsze niż poprzednie podejście oparte na fabryce? Zakładam, że jest jakiś inny przypadek użycia, o którym Nie wiem ale nie udało mi się tego zidentyfikować.

Jeśli zrozumiałem poniższe odpowiedzi, koncepcja jest taka, że framework DI działa jako fabryka obiektów nadrzędnych, która jest skonfigurowana centralnie. Czy to rozsądna interpretacja?

Update

Od tego czasu zacząłem uczyć się wiosny i teraz to ma o wiele więcej sensu. Poniższy akapit pochodzi z Spring in Practice na przykładzie klasy AccountService, która z kolei używa instancji AccountDao. Przepraszam. za długi cytat, ale myślę, że naprawdę dociera do sedna, dlaczego injected resources oferują coś ponad standardową inicjalizację.

można było zbudować AccountService za pomocą nowego słowa kluczowego, ale tworzenie obiektów warstwy usług rzadko jest tak proste. Często zależą od Dao, nadawców poczty, proxy Mydła i tego typu rzeczy. Można programowo utworzyć instancję każdej z tych zależności w konstruktorze AccountService (lub poprzez inicjalizację statyczną), ale prowadzi to do twardych zależności i kaskadowych zmian w miarę ich wymiany.

dodatkowo możesz tworzyć zależności zewnętrznie i ustawiać je na AccountService za pomocą metod setter lub argumentów konstruktora. Wyeliminowałoby to twarde wewnętrzne zależności (o ile zostały zadeklarowane w AccountService przez interfejs), ale kod inicjalizacji byłby zduplikowany wszędzie. Oto jak utworzyć DAO i podłączyć go na Twoje konto Wiosna sposób: 

<bean id="accountDao" class="com.springinpractice.ch01.dao.jdbc.JdbcAccountDao"/>

<bean id="accountService"
    class="com.springinpractice.ch01.service.AccountService">
    <property name="accountDao" ref="accountDao"/>
</bean>

Po skonfigurowaniu beans jak powyżej, Twój program może teraz zażądać wystąpienia {[4] } z aplikacji Springkontekst, a framework Spring DI zajmie się utworzeniem instancji wszystkiego, co wymaga utworzenia instancji.

Author: PhilDin, 2012-10-24
Source

4 answers

Ludzie, którzy napisali CDI dali ci jedną wielką fabrykę obiektów; wykonali pracę za Ciebie, lepiej niż ty byś to zrobił. Jest to konfiguracja XML lub adnotacja napędzana, więc nie musisz osadzać wszystkiego w kodzie.

Silniki wtryskowe, jak Spring, robią o wiele więcej niż Twoja fabryka. Potrzeba więcej niż jednej klasy fabrycznej i jednej linii kodu, aby zduplikować wszystko, co oferują.

Oczywiście, że nie musisz. Zawsze możesz wymyślić własne koło. A Ty should - jeśli twoim celem jest nauczenie się tworzenia kół lub wyeliminowanie zależności.

Ale jeśli chcesz po prostu tworzyć aplikacje, lepiej korzystać z narzędzi, które zapewniają inni, gdy dają ci przewagę.

Artykuł on dependency injection został napisany przez Martina Fowlera. Polecam lekturę, nadal jest świetna, osiem lat później.

"wciąż nie wiadomo, co jest więcej"

Oto kilka zalety:

  1. luźne sprzęgło
  2. łatwiejsze testowanie
  3. lepsze warstwowanie
  4. projektowanie oparte na interfejsie
  5. dynamiczne proxy (segue to AOP).
 48
Author: duffymo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-10-24 12:37:38

Celem użycia dependency injection jest to, że kod używający rzeczy, która została wstrzyknięta, nie ma zależności od fabryki. W przykładzie kodu fabrycznego wbudowane jest statyczne wywołanie metody, które nie jest tam potrzebne przy podejściu DI.

To, co jest wstrzykiwane myFoo nie powinno wiedzieć o fabryce. Fabryka ogranicza możliwości testowania, których nie ma Z DI.

 18
Author: Nathan Hughes,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-03-06 14:52:01

Jest to ważne i subtelne pytanie o to, na czym polega programowanie korporacyjne.

Nazwa jest dobrze dobrana: konteksty i zależności.

CDI nie ma nic wspólnego z lepszym lub czystszym kodem, chodzi o zapewnienie, że duże organizacje mogą budować złożone, rozproszone systemy oprogramowania i udostępniać dane. Chodzi o to, aby w 100% upewnić się, że rządy lub inne biurokracje mogą bezkrytycznie rozpowszechniać samodzielne, dobrze udokumentowane pakiety dla każdego kawałka oprogramowanie, które kontrolują. Pamiętaj, że w dzisiejszych czasach można wstrzyknąć praktycznie każde POJO.

Załóżmy, że budujesz jakąś aplikację kliencką i chcesz, aby wydrukowała imię użytkownika w rogu.

  • Architekci przedsiębiorstwa tej dużej firmy chcieliby, aby mieć tę zdolność, ale jako młodszy inżynier oprogramowania, nie ma szansa, że dostaniesz Klucze do DB.

  • Chcieliby również zabezpieczyć dane w całej sieci, ale Firma NIE PŁACI inżynierom za ponowne zaprojektowanie uwierzytelnienia klient za każdym razem, gdy musi udostępnić skrawek danych.

  • Chcieliby, abyś mógł móc odpytywać i aktualizować tej informacji, ale chciałby, aby transakcje były obsługiwane na wyższym poziom niż jakakolwiek aplikacja.

  • Chcieliby, abyś mógł przetestować swoje klasy z trywialnymi klockami w blokach konfiguracyjnych.

  • Chcieliby za łączenie klas do wymaga minimum metod statycznych.

  • I tak dalej i tak dalej...

Większość JSR prawdopodobnie ma " EAs chciałby być w stanie..."zakopane gdzieś w środku.

CDI jest preferowane, ponieważ pozwala aplikacjom o dużych (dowolnych?) skale poziome i pionowe w celu współdzielenia kontekstów, zależności, a tym samym danych.

W słowach Fowlera:

" problem polega na tym, jak zrobić ten link, aby moja klasa Listera była ignorant of the Klasa implementacji, ale nadal może rozmawiać z przykład do wykonania swojej pracy."

" ale jeśli chcemy wdrożyć ten system na różne sposoby, musimy użyj wtyczek do obsługi interakcji z tymi usługami, abyśmy mogli używaj różnych implementacji w różnych wdrożeniach."

" podejście, z którego korzystają te kontenery, ma zapewnić, że każdy użytkownik wtyczka jest zgodna z pewną konwencją, która pozwala na oddzielny asembler moduł do wprowadzania implementacji do lister."

W skrócie pozwalają na scentralizowane "sterowanie" złożonymi aplikacjami korporacyjnymi. Java EE jest usystematyzowanym, niezawodnym procesem abstrakcji, a CDI jest jego wcieleniem, które działa tak dobrze, że prawie czyni go niewidzialnym. To sprawia, że łączenie złożonych aplikacji jest niemal trywialne.

Jeszcze dwie rzeczy:

  1. Zauważ, że CDI istnieje obok "wzorca lokalizatora usług", znanego w Javie jako JNDI EE, co jest korzystne, jeśli programista klienta będzie musiał wybrać spośród wielu identycznie typowanych alternatyw.

  2. CDI ma większą siłę ognia niż jest to konieczne w wielu przypadkach, szczególnie w przypadkach niezwiązanych z przedsiębiorstwem (dosłownie).

 5
Author: jordanpg,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-01-05 00:46:28

Na wysokim poziomie, jak w przypadku większości rzeczy na CompSci, oferuje a level of indirection (lub abstrakcja), które w przeciwnym razie byłyby zakodowane na twardo w Twojej aplikacji jako Foo myFoo = new Foo();. Ten podział powoduje luźno sprzężony kod, który sprawia, że rzeczy są modularne, co ułatwia wymianę, obsługę, testowanie itp. klas lub podsystemów w prostszy sposób.

Zauważ, że istnieje wiele wzorów i wzorców dla indrection / abstraction - dependency injection jest po prostu jeden.

Innym aspektem twojego pytania jest "dlaczego CDI?"- cóż, ponieważ ktoś już wykonał pracę dla Ciebie. Możesz Zawsze budować własne rzeczy, ale zwykle jest to strata czasu, gdy celem jest zbudowanie systemu w prawdziwym świecie, który musi działać zgodnie z budżetem i na czas. Po co zawracać sobie głowę zakupami i gotowaniem, skoro jest szef kuchni nagrodzony gwiazdką Michelin, który jest gotów wykonać tę pracę za Ciebie?
 4
Author: DeepSpace101,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-07-31 15:46:18