Jakie są zalety/wady adnotacji (nie kompilator) w porównaniu do plików konfiguracyjnych xml

Question

Kiedy patrzę na środowiska Java takie jak Hibernate, JPA lub Spring, zazwyczaj mam możliwość wykonania konfiguracji za pomocą pliku xml lub umieszczaj adnotacje bezpośrednio na moich zajęciach.

Chętnie zadaję sobie pytanie, w którą stronę mam iść.

Kiedy używam adnotacji, mam klasę i jej konfigurację, ale z xml mam większy obraz mojego systemu, ponieważ widzę wszystkie konfiguracje klas.

Adnotacje również są kompilowane w pewien sposób, jak sądzę, i powinny być szybsze niż parsowanie xml, ale z drugiej strony, jeśli chcę zmienić konfigurację, muszę ją zrekompilować zamiast po prostu zmienić plik xml (który może stać się jeszcze bardziej przydatny w środowiskach produkcyjnych po stronie klienta).

Tak więc, patrząc na moje punkty, mam tendencję do pójścia drogą xml. Jednak podczas przeglądania forum lub samouczków zwykle używane są adnotacje.

Jakie są twoje plusy i minusy?

Answer 1

Dobra zasada: wszystko, co widzisz sam, chcąc zmienić bez pełnego przeniesienia (na przykład poprawić parametry wydajności) powinno naprawdę przejść w coś "konfigurowalnego", takiego jak plik XML. Wszystko, co nigdy nie zmieni się realistycznie - lub tylko w takiej sytuacji, w której i tak będziesz musiał zmienić kod - może znaleźć się w adnotacji.

Zignoruj ​​wszelkie różnice w wydajności między adnotacjami i XML - chyba że twoja konfiguracja jest absolutnie masywna różnica będzie niewielka.

Skoncentruj się na elastyczności i czytelności.

Answer 2

Jeśli piszesz interfejs API, ostrzeżenie: Adnotacje mogą wyciekać do interfejsu publicznego, co może być niewiarygodnie irytujące.

Obecnie pracuję z interfejsami API, w których dostawca API zasypuje swoją implementację adnotacjami w Spring MBean, co nagle oznacza, że ​​mam zależność od bibliotek Spring, pomimo możliwości, że nie będę musiał używać Springa :(

(oczywiście, jeśli API było przedłużenie do samej sprężyny, to może być ważne założenie.)

Answer 3

Myślę, że decyzja sprowadza się do „cyklu życia”, oraz niedopasowania impedancji pomiędzy cyklu życia.

Cykl życia: Każdy element danych, niezależnie od tego, czy jest to kod źródłowy, wiersz bazy danych, klasa skompilowana, obiekt, powiązany jest z cyklem życia. Kiedy powstaje i kiedy gromadzi śmieci?

Załóżmy, że umieszczam adnotacje Hibernate na klasie Java. Wydaje się, że jest to rozsądny pomysł, zwłaszcza jeśli tworzę nową bazę danych od podstaw i jestem pewien, że tylko ta jedna aplikacja kiedykolwiek się z nią połączy - cykl życia moich zajęć, schemat bazy danych i mapowanie ORM są z natury zsynchronizowane.

Załóżmy teraz, że chcę użyć tej samej klasy w interfejsie API i przekazać ją innej osobie do konsumpcji. Adnotacje Hibernate przenikają do mojego interfejsu API. Dzieje się tak, ponieważ cykl życia tej klasy i bazy danych to nie to samo. Tak więc w końcu używamy narzędzi mapujących do tłumaczenia między warstwami fasoli w systemie.

Staram się myśleć o cyklach życia i unikać adnotacji, które mogą powodować niedopasowanie cyklu życia. Niektóre adnotacje są stosunkowo nieszkodliwe pod tym względem, a niektóre stanowią ukryte niebezpieczeństwo.

Przykłady nieprawidłowych adnotacji: Mapowanie ORM, konfiguracja bazy danych, konfiguracja zakodowana dla elementów, które mogą się różnić między środowiskami wdrażania, sprawdzania poprawności, które mogą się różnić w zależności od kontekstu.

Przykłady nieszkodliwych adnotacji: Definicje punktów końcowych REST, serializacja JSON/XML, walidacje, które mają zawsze zastosowanie.