co lepiej używać adnotacji czy xml?
0
0
adnotacji
1
Polecam ani jedno ani drugie - słówko kluczowe 'new' jest super i robi to co potrzeba.
http://olivergierke.de/2013/11/why-field-injection-is-evil/
Dependency Injection doesn’t require a framework!
https://sites.google.com/site/unclebobconsultingllc/blogs-by-robert-martin/dependency-injection-inversion
0
IMO do konfiga(początkowy bajzel konfig) lepiej sprawdza się XML. A na codzień(wstrzyknięcia, serwisy, timery) adnotacje
1
To zależy co chcesz zrobić. Konfiguracja w XMLu, tak samo jak i używanie kontenera IoC mają swoje zastosowania, szczególnie w kontekscie rekonfigurowalnych aplikacji (chociaż podobne efekty można uzyskać też za pomocą jakiegoś OSGi).
Zacznijmy od samego kontenera IoC:
Masz tu możliwość automatycznego wykrywania komponentów z classpath i tworzenia ich razem z zależnościami. To oznacza że mozesz sobie wrzucić dodatkowego jara z pluginem i po restarcie aplikacji Spring sobie deployuje beany które tam są. Ty u siebie w aplikacji możesz sobie wstrzyknąć wszystkie wykryte beany danego typu (np. @Inject List<Plugin> plugins) i viola. To jest szczególnie istotne kiedy pluginy korzystają z jakichś serwisów dostarczanych przez "core" aplikacji, bo możemy potrzebować je sobie wstrzyknąć a nie tworzyć nowe.
Oczywiscie zaraz @jarekr000000 napisze ze przecież to samo można napisać samodzielnie bez użycia frameworka. I to prawda, można. Można porobić sobie ServiceLocatory / Singletony / Fabryki i stąd brać zależności. Można się dobrać do classloadera i czarować refleksją żeby instancjonować pluginy, ale w efekcie... będziemy pisać ten sam kod który ludzie od Springa już napisali i przetestowali :) Pytanie czy warto?
Konfiguracja w XMLu:
Poza wieloma niedogodnościami które oferuje, mamy tutaj jeden niewątpliwy plus. Mozemy zmienić xmla bez potrzeby rekompilacji projektu. Więc jeśli przewidujemy ze taka funkcjonalność może nam się przydać to można przemyśleć wyciągnięcie części konfiguracji do pliku xml. Oczywiście zwykle lepiej sobie to jakoś parametryzować a parametry trzymać w jakimś pliku properties i z niego ładować. Wtedy też mozemy zmienić konfiguracje bez rekompilacji. Niemniej może wystąpić taka sytuacja, że potrzebujemy mieć więcej "kontroli" i wtedy ten nieszczęsny xml może mieć sens.
0
Shalom napisał(a):
Oczywiscie zaraz @jarekr000000 napisze ze przecież to samo można napisać samodzielnie bez użycia frameworka. I to prawda, można. Można porobić sobie ServiceLocatory / Singletony / Fabryki i stąd brać zależności. Można się dobrać do classloadera i czarować refleksją żeby instancjonować pluginy, ale w efekcie... będziemy pisać ten sam kod który ludzie od Springa już napisali i przetestowali :) Pytanie czy warto?
Pytanie zasadnicze - czy ten człowiek, żebczywiście potrzebuje pluginów, classloaderów itp. Po co ? Jakbym robił projekt z classloaderami i pluginami to pewnie bym użył springa. Tylko do cholery nie robie np. Intellij :-) a tylko proste webserwery. (W prostym webserwerze jesst jeden classloader - nie ma WAR/ów - właśnie zdychają - zaraz po EARach).
Konfiguracja w XMLu:
Poza wieloma niedogodnościami które oferuje, mamy tutaj jeden niewątpliwy plus. Mozemy zmienić xmla bez potrzeby rekompilacji projektu. Więc jeśli przewidujemy ze taka funkcjonalność może nam się przydać to można przemyśleć wyciągnięcie części konfiguracji do pliku xml. Oczywiście zwykle lepiej sobie to jakoś parametryzować a parametry trzymać w jakimś pliku properties i z niego ładować. Wtedy też mozemy zmienić konfiguracje bez rekompilacji. Niemniej może wystąpić taka sytuacja, że potrzebujemy mieć więcej "kontroli" i wtedy ten nieszczęsny xml może mieć sens.
Trochę offtopic:
"bez potrzeby rekompilacji" - oczywiście czasem ma to czasem sens, ale zwykle jest to po prostu durny dowcip programistów .
Bo jak przyjdzie co do czego to i tak po zmianie XMLa - projekt jest budowany Mavenem i pakowany do Jara. Tak samo jak properties - po zmianie i tak trzeba (wygodniej) zwykle projekt przepakować (standardowo jak .props siedzą w /src/main/resources ). Nie widziałem raczej , żeby to było z sensem zrobione w springowych XML (powodzenia dla zespołu jak tam im admini lub userzy grzebią) i bardzo rzadko (1 na 10) w przypadku plików typu properties. Zwykle to tylko utrudnianie sobie życia - ludzie to lubią. Żeby podsumować do czego pije:
jeśli projekt jest czymś budowany - to generalnie nie widzę róznicy czy konfiguracja jest w XML, .properties czy w Java. To tylko format pliku i Java przykładowo zupełnie dobrze się do trzymania konfigów nadaje (a do tego są te konfigi kompilowane :-) ).
0
jarekr000000 napisał(a):
Polecam ani jedno ani drugie - słówko kluczowe 'new' jest super i robi to co potrzeba.
http://olivergierke.de/2013/11/why-field-injection-is-evil/
Dependency Injection doesn’t require a framework!
https://sites.google.com/site/unclebobconsultingllc/blogs-by-robert-martin/dependency-injection-inversion
Niby field injection jest evil... ale jakos nie mialem z tym nigdy wiekszych problemow, a kod wyglada duzo lepiej.