Configurazione XML rispetto alla configurazione basata su annotazioni [chiuso]

In alcuni grandi progetti a cui ho lavorato ultimamente sembra essere sempre più importante scegliere l'uno o l'altro (XML o Annotation). Man mano che i progetti crescono, la coerenza è molto importante per la manutenibilità.

Le mie domande sono: quali sono i vantaggi della configurazione basata su XML rispetto alla configurazione basata su annotazione e quali sono i vantaggi della configurazione basata su annotazione rispetto alla configurazione basata su XML?

Le annotazioni hanno il loro uso, ma non sono l'unico proiettile d'argento a uccidere la configurazione XML. Consiglio di mescolare i due!

Ad esempio, se si utilizza Spring, è del tutto intuitivo utilizzare XML per la parte di iniezione di dipendenza dell'applicazione. Ciò allontana le dipendenze del codice dal codice che lo utilizzerà, al contrario, l'utilizzo di una sorta di annotazione nel codice che necessita delle dipendenze rende il codice consapevole di questa configurazione automatica.

Tuttavia, invece di utilizzare XML per la gestione transazionale, contrassegnare un metodo come transazionale con un'annotazione ha perfettamente senso, poiché si tratta di informazioni che un programmatore vorrebbe probabilmente conoscere. Ma che un'interfaccia che verrà iniettata come Sottotipo invece di un Sottotipo non dovrebbe essere inclusa nella classe, perché se ora desideri iniettare Sottotipo, devi cambiare il tuo codice, mentre prima avevi un contratto di interfaccia, quindi con XML, dovresti solo cambiare i mapping XML ed è abbastanza veloce e indolore farlo.

Non ho usato le annotazioni JPA, quindi non so quanto siano buone, ma direi che lasciare anche la mappatura dei bean sul database in XML è buono, poiché all'oggetto non dovrebbe importare da dove provengono le sue informazioni , dovrebbe solo preoccuparsi di cosa può fare con le sue informazioni. Ma se ti piace JPA (non ho alcuna esperienza con esso), sicuramente, provaci.

In generale: se un'annotazione fornisce funzionalità e agisce come un commento in sé e per sé, e non lega il codice a un processo specifico per funzionare normalmente senza questa annotazione, scegli le annotazioni. Ad esempio, un metodo transazionale contrassegnato come transazionale non uccide la sua logica operativa e funge anche da buon commento a livello di codice. Altrimenti, questa informazione è probabilmente meglio espressa come XML, perché anche se alla fine influenzerà il funzionamento del codice, non cambierà la funzionalità principale del codice e quindi non appartiene ai file di origine.

C'è un problema più ampio qui, quello dei metadati esternalizzati rispetto a quelli incorporati. Se il tuo modello a oggetti è destinato a persistere in un solo modo, i metadati incorporati (ovvero le annotazioni) sono più compatti e leggibili.

Se, tuttavia, il modello a oggetti è stato riutilizzato in diverse applicazioni in modo tale che ciascuna applicazione volesse mantenere il modello in modi diversi, esternalizzare i metadati (ovvero i descrittori XML) diventa più appropriato.

Nessuno dei due è migliore, e quindi entrambi sono supportati, anche se le annotazioni sono più alla moda. Di conseguenza, i nuovi framework hair-on-fire come JPA tendono a porre maggiore enfasi su di essi. API più mature come Hibernate nativo offrono entrambi, perché è noto che nessuno dei due è sufficiente.

Penso sempre alle annotazioni come a una sorta di indicatore di cosa è capace una classe o di come interagisce con gli altri.

La configurazione XML di primavera invece per me è proprio questa, configurazione

Ad esempio, le informazioni sull'ip e sulla porta di un proxy, stanno sicuramente andando in un file XML, è la configurazione di runtime.

Usare @Autowire, @Elementper indicare al framework cosa fare della classe è un buon uso delle annotazioni.

Inserire l'URL @Webservicenell'annotazione è un cattivo stile.

Ma questa è solo la mia opinione. Il confine tra interazione e configurazione non è sempre chiaro.

Uso Spring da alcuni anni e la quantità di XML richiesta era decisamente noiosa. Tra i nuovi schemi XML e il supporto delle annotazioni nella primavera 2.5 di solito faccio queste cose:

1. Usando "component-scan" per caricare automaticamente le classi che usano @Repository, @Service o @Component. Di solito do un nome ad ogni bean e poi li collego usando @Resource. Trovo che questo impianto idraulico non cambi molto spesso, quindi le annotazioni hanno un senso.

2. Utilizzo dello spazio dei nomi "aop" per tutti gli AOP. Funziona davvero alla grande. Lo uso ancora anche per le transazioni perché mettere @Transactional dappertutto è una specie di trascinamento. È possibile creare punti di taglio con nome per i metodi su qualsiasi servizio o repository e applicare rapidamente i consigli.

3. Uso LocalContainerEntityManagerFactoryBean insieme a HibernateJpaVendorAdapter per configurare Hibernate. Ciò consente a Hibernate di individuare automaticamente le classi @Entity sul percorso di classe. Quindi creo un bean SessionFactory denominato usando "factory-bean" e "factory-method" facendo riferimento a LCEMFB.

Una parte importante nell'uso di un approccio solo per le annotazioni è che il concetto di "nome bean" più o meno scompare (diventa insignificante).

I "nomi dei bean" in Spring formano un ulteriore livello di astrazione rispetto alle classi di implementazione. Con i bean XML vengono definiti e referenziati in relazione al nome del loro bean. Con le annotazioni a cui fanno riferimento la loro classe / interfaccia. (Sebbene il nome del bean esista, non è necessario conoscerlo)

Credo fermamente che sbarazzarsi delle astrazioni superflue semplifichi i sistemi e migliori la produttività. Per i grandi progetti penso che i guadagni eliminando l'XML possano essere sostanziali.

Penso che la visibilità sia una grande vittoria con un approccio basato su XML. Trovo che l'XML non sia poi così male, dati i vari strumenti disponibili per la navigazione di documenti XML (ad esempio la finestra Struttura file di Visual Studio + ReSharper).

Puoi certamente adottare un approccio misto, ma questo mi sembra pericoloso se non altro perché, potenzialmente, renderebbe difficile per i nuovi sviluppatori di un progetto capire dove sono configurati o mappati oggetti diversi.

Non lo so; alla fine XML Hell non mi sembra poi così male.

Dipende da tutto ciò che vuoi configurare, perché ci sono alcune opzioni che non possono essere configurate con le anotazioni. Se lo vediamo dal lato delle annotazioni:

• Inoltre: le annotazioni sono meno chiacchierone
• meno: le annotazioni sono meno visibili

Dipende da te ciò che è più importante ...

In generale, consiglierei di scegliere un modo e usarlo in tutte le parti chiuse del prodotto ...

(con alcune eccezioni: ad es. se si scelgono configurazioni basate su XML, è possibile usare l'annotazione @Autowire. Si sta mescolando, ma questo aiuta sia la leggibilità che la manutenibilità)

Esistono altri aspetti da confrontare come il refactoring e altre modifiche al codice. quando si utilizza XML è necessario uno sforzo serio per effettuare il refactoring perché è necessario occuparsi di tutto il contenuto XML. Ma è facile quando si usano le annotazioni.

Il mio modo preferito è la configurazione basata su Java senza (o minima) annotazioni. http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java

Potrei sbagliarmi, ma ho pensato che le Annotazioni (come in @Tag di Java e [Attributo] di C #) fossero un'opzione di compilazione e XML fosse un'opzione di runtime. Questo per me dice che non sono equivalenti e hanno pro e contro diversi.

Penso anche che un mix sia la cosa migliore, ma dipende anche dal tipo di parametri di configurazione. Sto lavorando a un progetto Seam che utilizza anche Spring e di solito lo distribuisco su diversi server di sviluppo e test. Quindi ho diviso:

• Configurazione specifica del server (come i percorsi assoluti delle risorse sul server): file XML Spring
• Iniezione di bean come membri di altri bean (o riutilizzo di un valore definito Spring XML in molti bean): Annotazioni

La differenza fondamentale è che non è necessario ricompilare il codice per tutte le modifiche alle configurazioni specifiche del server, basta modificare il file xml. C'è anche il vantaggio che alcuni membri del team possono apportare alcune modifiche alla configurazione che non comprendono tutto il codice coinvolto.

Nell'ambito del contenitore DI, ritengo che DI basato sull'annotazione stia abusando dell'uso dell'annotazione Java. Detto questo, non consiglio di usarlo ampiamente nel tuo progetto. Se il tuo progetto ha davvero bisogno della potenza del contenitore DI, consiglierei di usare Spring IoC con l'opzione di configurazione basata su Xml.

Se è solo per motivi di Unit-test, gli sviluppatori dovrebbero applicare il modello Inject Dependency nella loro codifica e trarre vantaggio da strumenti beffardi come EasyMock o JMock per aggirare le dipendenze.

Dovresti cercare di evitare l'uso del contenitore DI nel suo contesto sbagliato.

Le informazioni di configurazione che saranno sempre collegate a un componente Java specifico (classe, metodo o campo) sono un buon candidato per essere rappresentate da annotazioni. Le annotazioni funzionano particolarmente bene in questo caso quando la configurazione è fondamentale per lo scopo del codice. A causa delle limitazioni sulle annotazioni, è anche meglio quando ogni componente può avere una sola configurazione. Se è necessario gestire più configurazioni, in particolare quelle che sono condizionate da qualsiasi cosa al di fuori della classe Java contenente un'annotazione, le annotazioni possono creare più problemi di quanti ne risolvano. Infine, le annotazioni non possono essere modificate senza ricompilare il codice sorgente Java, quindi tutto ciò che deve essere riconfigurabile in fase di esecuzione non può utilizzare le annotazioni.

Si prega di fare riferimento ai seguenti collegamenti. Potrebbero anche essere utili.

1. Annotazioni vs XML, vantaggi e svantaggi
2. http://www.ibm.com/developerworks/library/j-cwt08025/

Questa è la classica domanda "Configurazione contro Convenzione". Il gusto personale determina la risposta nella maggior parte dei casi. Tuttavia, personalmente preferisco la configurazione (ovvero basata su XML) rispetto alla convenzione. Gli IDE IMO sono sufficientemente robusti da superare alcuni degli inferi XML che le persone spesso associano con l'edificio e mantenendo un approccio basato su XML. Alla fine, trovo che i vantaggi della configurazione (come la creazione di utility per creare, mantenere e distribuire il file di configurazione XML) superano la Convenzione a lungo termine.

Uso entrambi. Principalmente XML, ma quando ho un sacco di bean che ereditano da una classe comune e hanno proprietà comuni, uso le annotazioni per quelli, nella superclasse, quindi non devo impostare le stesse proprietà per ogni bean. Dato che sono un po 'un maniaco del controllo, uso @Resource (name = "referBean") invece di autorizzare cose (e mi risparmio un sacco di problemi se mai avessi bisogno di un altro bean della stessa classe dell'originale referBean) .

Dalla mia esperienza ci sono alcuni vantaggi e svantaggi della configurazione delle annotazioni:

• Quando si tratta di configurazione JPA poiché viene eseguita una volta e di solito non viene modificata abbastanza spesso, preferisco attenermi alla configurazione delle annotazioni. Forse c'è una preoccupazione per quanto riguarda la possibilità di vedere un quadro più ampio della configurazione: in questo caso utilizzo i diagrammi di MSQLWorkbench.
• La configurazione XML è molto buona per ottenere un'immagine più ampia dell'applicazione, ma può essere ingombrante trovare alcuni errori fino al runtime. In questo caso l' annotazione Spring @Configuration suona come una scelta migliore poiché consente di vedere un'immagine più ampia e consente anche di convalidare la configurazione in fase di compilazione.
• Per quanto riguarda la configurazione di Spring, preferisco combinare entrambi gli approcci: utilizzare l' annotazione @Configuration con le interfacce Services e Query e la configurazione xml per dataSource e configurazioni di primavera come contesto: component-scan base-package = "..."
• Ma la configurazione xml inserisce annotazioni java quando si tratta di configurazione del flusso (Spring Web Flow o Lexaden Web Flow) poiché è estremamente importante vedere un quadro più ampio dell'intero processo aziendale. E sembra ingombrante averlo implementato con l'approccio delle annotazioni.

Preferisco combinare entrambi gli approcci: annotazioni java e minimo essenziale xml che minimizzano l'inferno della configurazione.

Per Spring Framework mi piace l'idea di poter usare l'annotazione @Component e impostare l'opzione "scan componente" in modo che Spring possa trovare i miei java bean in modo da non dover definire tutti i miei bean in XML, né in JavaConfig. Ad esempio, per i bean java singleton senza stato che devono semplicemente essere collegati ad altre classi (tramite un'interfaccia idealmente) questo approccio funziona molto bene. In generale, per i bean Spring mi sono allontanato per lo più dal DSL Spring XML per la definizione dei bean, e ora favorisco l'uso di JavaConfig e Spring Annotations perché si ottiene un controllo del tempo di compilazione della propria configurazione e un supporto di refactoring che non si ' ottenere con la configurazione XML di primavera. Mescolo i due in alcuni rari casi in cui ho scoperto che JavaConfig / Annotations non può fare ciò che è disponibile usando la configurazione XML.

Per Hibernate ORM (non ho ancora usato JPA) preferisco ancora i file di mapping XML perché le annotazioni nelle classi dei modelli di dominio violano in qualche modo The Clean Architecture, che è uno stile architettonico stratificato che ho adottato negli ultimi anni. La violazione si verifica perché richiede al Core Layer di dipendere da elementi relativi alla persistenza come le librerie Hibernate o JPA e rende i POJO del modello di dominio un po 'meno persistenti nell'ignoranza. In effetti il ​​Core Layer non dovrebbe dipendere da nessun'altra infrastruttura.

Tuttavia, se The Clean Architecture non è la tua "tazza di tè", allora posso vedere che ci sono sicuramente vantaggi (come la convenienza e la manutenibilità) dell'uso delle annotazioni Hibernate / JPA nelle classi del modello di dominio rispetto a file di mapping XML separati.