Ci sono degli svantaggi nel legare la mia applicazione al framework Spring?
Non sto parlando di bug o problemi del genere, se ce ne sono. Sto parlando di cose strategiche e architettoniche che influenzeranno il ciclo di vita delle mie applicazioni.
Dovrei preferire le funzionalità principali Spring EE Java supportate dal contenitore EE? Quali sono i vantaggi?
Poiché altri post qui menzionano il lato positivo, menzionerò gli aspetti negativi di Spring. Anche con questi aspetti negativi, Spring è onnipresente nella sua nicchia, affidabile e funziona come pubblicizzato.
Quindi, ai negativi:
Enorme: non vorrei mettere vasi con 3000 classi nel mio piccolo progetto per hobby.
Ci sono alcune descrizioni di esso più lente di altri framework DI come Guice o Pico. aneddotico, e probabilmente non troppo importante.
Affrontare alcune parti della primavera può essere frustrante quando non sono parti del nucleo ben documentate e la documentazione che trovi differisce tra le diverse versioni principali.
Come effetto collaterale delle sue dimensioni, preparati a trascorrere ore gioiose scavando tra le pile di classi che, se nominate logicamente, iniziano a fondere insieme in una gigantesca pila di nomi quando sei stanco ("certo, ti basta collegare il tuo TransactionAwareConnectionFactoryProxy al tuo UserCredentialsConnectionFactoryAdapter al tuo .. zzzzzzzz "). Per essere onesti, sono davvero nominati logicamente, è una risposta ragionevole alle dimensioni del framework, ma comunque.
Forse a causa di questo adattamento di nuovi pezzi, la primavera può essere lenta, almeno per me. Non tanto con la molla di base, ma ci sono connettori per quasi tutto, e non sono tutti ben documentati come potrebbero essere, e questo è quando inizi a guado attraverso la zuppa dei nomi. Di nuovo, è davvero tutto solo in risposta alle sue dimensioni.
Ci sono pochissimi aspetti negativi in primavera
Ho pensato a lungo e duramente per trovare seri svantaggi nell'usare Spring, e temo di aver fallito. Spring è un eccellente toolkit all'interno dei modelli JEE / OSGi. Fornisce una vasta gamma di modelli non invasivi che semplificano notevolmente il lavoro con le API di supporto spesso ingombranti fornite dai contenitori delle applicazioni.
Spring vs the core JEE
Spring non sostituisce le tecnologie JEE core - beh forse EJBs ma con la nuova specifica EJB3 non c'è quasi nulla in esso - invece fornisce modelli per renderne l'uso molto più semplice. Considera JAX-RS l'API dei servizi web RESTful. Spring fornisce il RestTemplate che viene in genere utilizzato come segue (supponiamo che sia iniettato):
SomeJaxbAnnotatedClass object = restTemplate.getForObject(someURI,SomeJaxbAnnotatedClass.class);
Questo andrà a someURI per ottenere XML / JSON / YAML e renderlo unmarshal nell'oggetto dominio specificato. Tutto in un'unica riga di codice.
Le eccezioni e la registrazione degli errori vengono gestite come eccezioni di runtime, rendendo più semplice mantenere pulito il codice locale. Spring funziona anche per ridurre le dipendenze esterne laddove possibile, quindi l'esempio precedente utilizza solo i pacchetti java.net. *).
Esistono modelli per JMS, JAX-WS, JPA, JTA e così via. Tutti lo rendono molto più facile da utilizzare con questi standard e rendono il tuo codice più pulito e meno soggetto a errori.
Architettura Pick'n'mix
Da un punto di vista architettonico, Spring enfatizza un approccio pick'n'mix leggero. Ciò ha l'effetto di consentire agli architetti di sistema di evitare l'uso di contenitori di applicazioni all-in-tutti gonfiati come WebSphere, JBoss o Glassfish e scegliere invece le loro controparti leggere - Jetty, Tomcat e così via.
Perché è così importante? I contenitori applicativi più grandi hanno un ciclo di aggiornamento molto più lungo che si adatta alle esigenze di alcuni clienti più di altri. Le banche non hanno bisogno di essere agili come una startup one man.
Se si desidera utilizzare l'ultima versione dei framework di supporto, è improbabile trovarli nei contenitori delle applicazioni di grandi dimensioni. Invece, dovrai includerli manualmente e Spring lo renderà più semplice.
Inoltre, devi solo includere specificamente le tecnologie di cui hai bisogno. I contenitori delle applicazioni ti daranno JMS, EJB e ogni altro acronimo sotto il sole, ma vuoi solo una facile persistenza con JPA. Include Spring e Hibernate e il gioco è fatto.
Allora perché non Spring?
Evita Spring se vuoi andare con le implementazioni specifiche delle vendor delle librerie. Inoltre, evitalo se si desidera mantenere i dettagli di configurazione all'interno delle classi piuttosto che esternalizzarle in XML o JNDI. E sicuramente evitarlo se pensi che le soluzioni gratuite e open source non siano adatte al tuo ambiente.
una cosa interessante che Martin Thompson menziona in questo articolo è che la primavera può avere un impatto non banale sui tempi di GC:
Keep call stacks reasonably small. Still more work to do here. If you are crazy enough to use Spring, then check out your call stacks to see what I mean! The garbage collector has to walk them finding reachable objects. -Martin Thompson
Questo tipo di cose non sarà un grosso problema per la maggior parte delle app, ma è una vera preoccupazione per i tipi di app a cui Martin si riferisce.
La primavera è davvero buona. Spring Core va bene. Vorrei aggiungere agli altri punti, se siete nella categoria di nicchia in cui le prestazioni sono davvero una preoccupazione, vorrete evitare gli altri moduli Spring, solo se siete nelle mani dei migliori sviluppatori. Questo è solo un problema se stai utilizzando un sistema in cui le prestazioni sono davvero importanti. Nelle mani di sviluppatori mediocri o buoni, Spring probabilmente ti darà un incremento delle prestazioni aiutando a scrivere codice semplice e pulito.
La primavera è ormai diventata parte della piattaforma ora. Ovunque in JEE5 e 6 trovi sempre più risorse per l'iniezione, quindi almeno quella parte di Spring, se la mantieni, è / sarà solo un'altra parte della piattaforma, (vedi @Inject). Altre parti ... non sono sicure, specialmente quando si tratta di programmazione orientata all'aspetto. Ci sono altri fornitori di questi servizi, Guice, originariamente di Google, e Weld, di JBoss, credo costruito su Guice, fornirà la stessa funzionalità se si atterrà alle specifiche di integrazione delle dipendenze Java di JSR-330.
YMMV
Spring si sforza di essere non invasivo in termini di mantenerlo liberamente collegato al codice dell'applicazione.
Si sta anche muovendo più in quella direzione per il tiem. Nelle versioni precedenti era necessario estendere le classi di base, quindi spostarle in annotazioni e al giorno d'oggi è sempre più l'uso di POJO configurati in XML.
Questo è un enorme vantaggio strategico rispetto ad altri framework applicativi.