Konfiguracja Xml a konfiguracja oparta na adnotacjach [zamknięta]

Istnieje szerszy problem tutaj, że z uzewnętrznionych vs inlined meta-dane. Jeśli twój model obiektowy ma trwać tylko w jeden sposób, wówczas metadane inlined (tj. adnotacje) są bardziej zwarte i czytelne.

Jeśli jednak twój model obiektowy został ponownie użyty w różnych aplikacjach w taki sposób, że każda aplikacja chciała utrzymać model na różne sposoby, wtedy bardziej odpowiednie staje się eksternalizacja metadanych (np. deskryptorów XML).

Żaden nie jest lepszy, a tak więc oba są obsługiwane, chociaż adnotacje są bardziej modne. W rezultacie nowe struktury hair-on-fire, takie jak JPA, kładą na nich większy nacisk. Bardziej dojrzałe API, takie jak native Hibernate, oferują oba, ponieważ wiadomo, że żaden z nich nie wystarczy.

Zawsze myślę o adnotacjach jako pewnego rodzaju wskaźniku do czego klasa jest zdolna lub Jak współdziała z innymi.

Spring XML configuration natomiast dla mnie jest to po prostu, configuration

Na przykład informacja o ip i porcie proxy, jest definitywnie zapisywana do pliku XML, jest to konfiguracja runtime.

Za pomocą @Autowire,@Element aby wskazać framework, co zrobić z klasą, należy dobrze wykorzystać Przypisy

Umieszczenie adresu URL w adnotacji @Webservice jest złym stylem.

Używam Springa od kilku lat i ilość XML, która była wymagana, była zdecydowanie nudna. Pomiędzy nowymi schematami XML a Obsługą adnotacji na wiosnę 2.5 zwykle robię takie rzeczy:

1. Używanie "component-scan" do klas autoload, które używają @ Repository, @ Service lub @Component. Zwykle nadaję każdej fasoli nazwę, a następnie łączę je razem za pomocą @ Resource. Uważam, że ta hydraulika nie zmienia się zbyt często, więc adnotacje sprawiają, że sens.

2. Korzystanie z przestrzeni nazw " aop " dla wszystkich AOP. To naprawdę działa świetnie. Nadal używam go również do transakcji, ponieważ umieszczenie @Transactional wszędzie jest trochę trudne. Możesz tworzyć nazwane skróty dla metod w dowolnej usłudze lub repozytorium i bardzo szybko zastosować porady.

3. Używam LocalContainerEntityManagerFactorybean wraz z HibernateJpaVendorAdapter do konfiguracji Hibernate. Pozwala to hibernować łatwo automatycznie wykrywać klasy @ Entity na classpath. Następnie tworzę nazwaną SessionFactory bean używając "factory-bean" i "factory-method" odnoszących się do lcemfb.

Ważnym elementem w używaniu tylko adnotacji jest to, że pojęcie "nazwa fasoli" mniej lub bardziej odchodzi (staje się nieistotne).

" nazwy fasoli " na wiosnę tworzą dodatkowy poziom abstrakcji nad klasami implementującymi. Za pomocą XML beans są definiowane i odwoływane względem ich nazwy bean. Z adnotacjami są one odwoływane przez ich klasę / interfejs. (Chociaż nazwa fasoli istnieje, nie musisz jej znać)

Mocno wierzę, że pozbycie się zbędnych abstrakcji upraszcza systemy i poprawia produktywność. Dla dużych projektów myślę, że korzyści wynikające z pozbycia się XML mogą być znaczne.

Myślę, że widoczność to duża wygrana dzięki podejściu opartemu na XML. Uważam, że XML nie jest tak źle, biorąc pod uwagę różne narzędzia tam do nawigacji dokumentów XML (TJ Visual Studio + ReSharper ' s file Structure window).

Z pewnością można przyjąć mieszane podejście, ale wydaje mi się to niebezpieczne, choćby dlatego, że potencjalnie utrudni to Nowym programistom w projekcie ustalenie, gdzie różne obiekty są skonfigurowane lub zmapowane.

Nie wiem; w końcu piekło XML nie wydaje mi się takie złe.

To zależy od tego, co chcesz skonfigurować, ponieważ są pewne opcje, których nie można skonfigurować za pomocą anotacji. Jeśli widzimy to od strony adnotacji:

• plus: adnotacje są mniej gadatliwe
• minus: adnotacje są mniej widoczne

To od Ciebie zależy, co jest ważniejsze...

Ogólnie polecam wybrać jeden sposób i użyć go na jakiejś zamkniętej części produktu...

(z pewnymi wyjątkami: np. jeśli wybierzesz XML konfiguracje oparte, można używać adnotacji @ Autowire. To mieszanie, ale ten pomaga zarówno czytelność, jak i konserwację)

Są inne aspekty do porównania, takie jak refaktoryzacja i inne zmiany w kodzie. podczas korzystania z XML wymaga surowatego wysiłku, aby refaktoryzacji, ponieważ trzeba dbać o całą zawartość XML. Ale jest to łatwe przy użyciu adnotacji.

Moim preferowanym sposobem jest konfiguracja oparta na Javie bez (lub minimalnych) adnotacji. http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java

Może się mylę, ale myślałem, że adnotacje (jak w Javie @Tag i C#[atrybut]) są opcją kompilacji, a XML opcją run-time. To mi mówi, że nie są równoważne i mają różne plusy i minusy.

Myślę też, że mix jest najlepszą rzeczą, ale zależy to również od rodzaju parametrów konfiguracyjnych. Pracuję nad projektem Seam, który również wykorzystuje Spring i zazwyczaj wdrażam go na różnych serwerach deweloperskich i testowych. Więc się rozdzieliłem:

• Konfiguracja specyficzna dla serwera (jak ścieżki bezwzględne do zasobów na serwerze): plik XML Spring
• Injing beans as members of other beans (or reusing a Spring XML defined value in many beans): Adnotations

Klucz różnica polega na tym, że nie musisz rekompilować kodu dla wszystkich zmieniających się konfiguracji specyficznych dla serwera, po prostu edytuj plik xml. Zaletą jest również to, że niektóre zmiany konfiguracyjne mogą być dokonywane przez członków zespołu, którzy nie rozumieją całego kodu.

W zakresie kontenera DI uważam, że DI oparte na adnotacji nadużywa używania adnotacji Java. Mówiąc to, nie polecam, aby używać go szeroko w swoim projekcie. Jeśli twój projekt naprawdę potrzebuje mocy kontenera DI, polecam użyć Spring IoC z opcją konfiguracji opartej na Xml.

Jeśli jest to tylko ze względu na Unit-test, programiści powinni zastosować wzorzec iniekcji zależności w swoim kodowaniu i skorzystać z narzędzi kpiących, takich jak EasyMock lub JMock, aby obejść zależności.

Powinieneś unikać używania kontenera DI w jego niewłaściwym kontekście.

Informacje konfiguracyjne, które zawsze będą powiązane z określonym komponentem Java (klasą, metodą lub polem), są dobrym kandydatem do reprezentowania przez adnotacje. Adnotacje działają szczególnie dobrze w tym przypadku, gdy konfiguracja jest rdzeniem kodu. Ze względu na ograniczenia dotyczące adnotacji najlepiej jest również, gdy każdy komponent może mieć tylko jedną konfigurację. Jeśli potrzebujesz poradzić sobie z wieloma konfiguracjami, zwłaszcza tymi, które są uzależnione od czegokolwiek poza klasą Java zawierającą adnotację, adnotacje mogą tworzyć więcej problemów niż rozwiązują. Adnotacje nie mogą być modyfikowane bez rekompilacji kodu źródłowego Javy, więc wszystko, co wymaga rekonfiguracji w czasie działania, nie może używać adnotacji.

Proszę zapoznać się z poniższymi linkami. Mogą się też przydać.

1. adnotacje vs XML, zalety i wady
2. http://www.ibm.com/developerworks/library/j-cwt08025/

Jest to klasyczne pytanie "Konfiguracja a konwencja". Osobisty gust dyktuje odpowiedź w większości przypadków. Jednak osobiście wolę konfigurację (tj. opartą na XML) niż Konwencję. IMO IDE są wystarczająco wytrzymałe, aby przezwyciężyć niektóre z piekła XML ludzie często kojarzą w / budynku i utrzymania podejścia opartego na XML. W końcu uważam, że korzyści z konfiguracji (takie jak budowanie narzędzi do budowania, utrzymywania i wdrażania pliku konfiguracyjnego XML) przeważają Zjazd na dłuższą metę.

Używam obu. Głównie XML, ale kiedy mam kilka fasoli, które dziedziczą ze wspólnej klasy i mają wspólne właściwości, używam adnotacji dla nich, w superklasie, więc nie muszę ustawiać tych samych właściwości dla każdej fasoli. Ponieważ jestem trochę maniakiem kontroli, używam @ Resource (name="referredBean") zamiast tylko autowiringu (i oszczędzę sobie wiele kłopotów, jeśli kiedykolwiek będę potrzebował innej fasoli tej samej klasy, co oryginalna referredBean).

Są pewne plusy i minusy konfiguracji adnotacji z mojego doświadczenia:

• Jeśli chodzi o konfigurację JPA, ponieważ jest ona wykonywana raz i zazwyczaj nie są zmieniane dość często wolę trzymać się konfiguracji adnotacji. Być może istnieje obawa o możliwość zobaczenia większego obrazu konfiguracji - w tym przypadku korzystam z diagramów MSQLWorkbench.
• Konfiguracja Xml jest bardzo dobra, aby uzyskać szerszy obraz aplikacji, ale może kłopotliwe jest znalezienie błędów do czasu uruchomienia. W tym przypadku adnotacja Spring @Configuration jest lepszym wyborem, ponieważ pozwala zobaczyć większy obraz, a także pozwala zweryfikować konfigurację w czasie kompilacji.
• jeśli chodzi o konfigurację Spring, wolę połączyć oba podejścia: użyj @Configuration adnotacji z interfejsami usług i zapytań oraz konfiguracji xml dla dataSource i konfiguracji spring, takich jak context:component-scan base-package="..."
• ale konfiguracja xml bits Java adnotacje, jeśli chodzi o konfigurację przepływu (Spring Web Flow lub Lexaden Web Flow), ponieważ niezwykle ważne jest, aby zobaczyć większy obraz całego procesu biznesowego. I wydaje się kłopotliwe, aby to zaimplementować z podejściem adnotacji.

Wolę łączyć oba podejścia-adnotacje java i niezbędne minimum xml, które minimalizują konfigurację.

Dla Spring Framework podoba mi się pomysł użycia adnotacji @Component i ustawienia opcji "component-scan", aby Spring mógł znaleźć moje java beans, tak że nie muszę definiować wszystkich moich beans w XML, ani w JavaConfig. Na przykład, dla bezpaństwowych ziaren Javy singleton, które po prostu muszą być podłączone do innych klas (najlepiej przez interfejs), to podejście działa bardzo dobrze. Ogólnie rzecz biorąc, dla fasolek wiosennych w większości odsunąłem się od Spring XML DSL do definiowania beans, a teraz korzystaj z adnotacji JavaConfig i Spring, ponieważ masz trochę czasu kompilacji sprawdzania konfiguracji i trochę wsparcia refaktoryzacji, którego nie masz w konfiguracji Spring XML. Mieszam te dwa w pewnych rzadkich przypadkach, gdy odkryłem, że JavaConfig / adnotacje nie mogą zrobić tego, co jest dostępne za pomocą konfiguracji XML.

Dla Hibernate ORM (nie używałem jeszcze JPA) nadal wolę pliki mapowania XML ponieważ adnotacje w klasach modelu domeny do pewnego stopnia narusza czystą architekturę , która jest warstwowym stylem architektonicznym, który zaadoptowałem w ciągu ostatnich kilku lat. Naruszenie występuje, ponieważ wymaga, aby warstwa podstawowa była zależna od rzeczy związanych z trwałością, takich jak biblioteki Hibernate lub JPA i sprawia, że model domeny jest nieco mniej trwały. W rzeczywistości Warstwa Podstawowa nie powinna w ogóle zależeć od żadnej innej infrastruktury.

Jeśli jednak czysta Architektura nie jest twoją "filiżanką herbaty" to widzę istnieją zdecydowanie zalety (takie jak wygoda i łatwość utrzymania) używania adnotacji Hibernate/JPA w klasach modelu domeny nad oddzielnymi plikami mapowania XML.