Cosa sono i pro/contro delle annotazioni (non compilatore) rispetto ai file di configurazione xml

Question

Quando guardo framework Java come Hibernate, JPA o Spring, di solito ho la possibilità di configurare la mia configurazione tramite un file xml o metti le annotazioni direttamente nelle mie classi.

Mi chiedo con costanza in che modo dovrei andare.

Quando uso le annotazioni, ho la classe e la sua configurazione insieme ma con un xml ottengo un'immagine più grande del mio sistema perché posso vedere tutte le configurazioni di classe.

Le annotazioni vengono anche compilate in qualche modo credo e dovrebbe essere più veloce di analizzare l'xml, ma d'altra parte, se voglio cambiare la mia configurazione, devo ricompilarlo invece di cambiare semplicemente il file xml (che potrebbe diventare ancora più comodo per gli ambienti di produzione dal lato del cliente).

Quindi, quando guardo i miei punti, tendo ad andare in modo xml. Ma quando si utilizzano forum o tutorial vengono solitamente utilizzate annotazioni.

Quali sono i pro e i contro?

Answer 1

Una buona regola empirica: tutto ciò che si può vedere si desidera modificare senza una ridistribuzione completa (ad esempio, i parametri di ottimizzazione del tweaking) dovrebbe andare in qualcosa di "soft-configurabile" come un file XML. Qualunque cosa che non cambierà mai realisticamente - o solo nel tipo di situazione in cui dovrete modificare il codice in ogni caso - può ragionevolmente essere in un'annotazione.

Ignora qualsiasi idea di differenze di prestazioni tra le annotazioni e XML - a meno che la tua configurazione non sia assolutamente massiva la differenza sarà insignificante.

Concentrato su flessibilità e leggibilità.

Answer 2

Se stai scrivendo un'API, quindi una parola di avvertimento: le annotazioni possono infiltrarsi nella tua interfaccia pubblica che può essere incredibilmente esasperante.

Attualmente sto lavorando con API in cui il fornitore dell'API ha condizionato la sua implementazione con le annotazioni Spring MBean, che improvvisamente significa che ho una dipendenza dalle librerie Spring, nonostante la possibilità che non sia necessario utilizzare Spring per niente :(

(Naturalmente, se la vostra API era un'estensione a molla stessa, questo potrebbe essere un presupposto valido.)

Answer 3

credo che la decisione si riduce a 'ciclo di vita', e disadattamento di impedenza tra i cicli di vita.

Ciclo di vita: Ogni dato, sia esso il codice sorgente, una riga del database, una classe compilata, un oggetto, ha un ciclo di vita associato. Quando viene alla luce e quando viene raccolta la spazzatura?

Supponiamo di aver inserito le annotazioni Hibernate su una classe Java. Sembra un'idea ragionevole, soprattutto se sto creando un nuovo database da zero e sono fiducioso che solo questa unica applicazione si collegherà ad esso - i cicli di vita delle mie classi, lo schema del database e la mappatura ORM sono naturalmente sincronizzati.

Ora supponiamo di voler utilizzare quella stessa classe in un'API e di fornirla a terze parti da consumare. Le annotazioni di Hibernate si diffondono nella mia API. Questo accade perché il ciclo di vita di quella classe e il database non sono la stessa cosa. Quindi finiamo per usare gli strumenti di mappatura per tradurre tra strati di fagioli in un sistema.

Provo a pensare ai cicli di vita e quelle annotazioni che possono causare errori di ciclo di vita dovrebbero essere evitati. Alcune annotazioni sono relativamente innocue sotto questo aspetto, e alcune sono un pericolo nascosto.

Esempi di annotazioni errate: Mappatura ORM, configurazione del database, configurazione codificata per gli elementi che possono variare tra gli ambienti di distribuzione, convalide che possono variare in base al contesto.

Esempi di annotazioni innocue: Definizioni endpoint REST, serializzazione JSON/XML, convalide che si applicano sempre.