Ei bine, în primul rând, pe lângă configurația XML, primăvara permite ajustarea cu adnotări, pe care unii o consideră o abordare mai convenabilă.
În general, primăvara este mai mult decât un container IoC, deși este partea sa esențială. Primavara este un cadru larg cu aplicatie proprie. La un moment dat la proiect, am refuzat-o în favoarea google-guice, tk. numai IoC a fost necesară.
integrală. Spring Roo - convenție asupra configurației și nu XML
este bine, dar nu răspunde la întrebarea: de ce am nevoie de primăvară în cererea mea?
Și nimeni nu garantează că aveți nevoie de ea în cererea dumneavoastră. Cel mai probabil, odată ce a apărut o astfel de întrebare - nu are nevoie de ea
Și ce fel de aplicație aveți?
Nu este vorba despre o aplicație specifică, ci mai degrabă o continuare a discuțiilor cu privire la utilizarea izvoarelor în toate aplicațiile la rând
Și puteți da un exemplu de utilizare adecvată a izvoarelor în aplicație?
Primăvara este potrivită dacă aplicația este implementată într-un volum, de exemplu, și aveți nevoie de gestionarea automată a tranzacțiilor etc.
Deși în acest caz aș fi blocat într-o tomboană opinăb.
Mi se pare cel mai potrivit să o folosesc dacă există o perspectivă de utilizare în aplicația AOP, tranzacțiile la nivelul obiectului, dacă modelul de acces la date este probabil să se schimbe. Nu am folosit-o niciodată pentru a implementa interfața web, dar am auzit despre câteva caracteristici importante, cum ar fi Spring Web MVC + Spring Web Flow, securitatea de primăvară. Ei bine, alte tehnologii interesante cum ar fi JMX, JMI, RPC (RMI, SOAP)
Desigur, puteți alege orice teanc de tehnologii, este mai mult o chestiune de gust și de experiență cu fiecare dintre ele. Principalul lucru este fără fanatism. Într-un proiect amplu cu AOP am folosit Spring, pentru un container curat IoC fără excese - nu.
Primăvara sa născut ca o alternativă la EE - spun ei, este prea greoaie în majoritatea cazurilor. Și nu se pot opri. Acum este "totul nostru" și ei înșiși devin monștri.
De ce am nevoie de o primăvară cu fișierul xml-config și doresc cu adevărat oamenii să o facă pentru IoC?
Dacă luăm în considerare doar IoC, atunci:
1. Fără IoC, aplicațiile arată uluitoare datorită utilizării de țesături și unic, ceea ce face ca aplicațiile să fie dificil de testat și de lemn.
2. IoC de primăvară - este simplu ca un baston, pentru studiul său va fi suficient pentru o zi incompletă (desigur, pentru o cunoaștere profundă a zilei nu este suficientă, dar cunoștințe profunde nu este necesară pentru a putea folosi DI).
3. Nu trebuie să folosesc Spring pentru IoC: există același Guice, puteți chiar să îngropați Fabrica IoC, deși nu sunt sigur că va fi rulat pe aplicații mari.
Principiul inversării dependenței, cuplajul redus, coeziunea ridicată, prin urmare: ușurința reutilizării componentelor și înțelegerea codului.
Apropo, IMHO, o întrebare foarte corectă. Eu însumi am rezistat izvoarelor până la ultima. A trebuit să folosesc, pentru că nimic mai bun decât Spring Security nu a fost găsit. Acum folosesc Spring Security și Spring JPA (+ JPA Generic Dao, + ZK).
* Nu pot spune nimic rău despre primăvară, cu excepția a aproximativ 2-3 zile petrecute în scrierea xml configs. În plus, puteți simți "greutatea" izvoarelor pe gazde.
* Nimic bun despre primăvară, de asemenea, nu pot spune. Se pare că tot ceea ce se face prin izvoare se poate face mai ușor, prin aceleași adnotări (chiar dacă este prin izvoare la nivelul inferior, așa cum funcționează în Grails).
IMHO, pentru dezvoltarea site-ului Web Spring - cel mai bun din Java.
Aceasta este o soluție integrată atentă. Singurul dezavantaj al acesteia este o configurație complexă. Dar există ROO.
EE - pentru dezvoltarea web este slab potrivită. JSF are probleme cu SEO și utilitatea. EJB nu poate fi legat la o sesiune de utilizator.
Afișați toate link-urile către acest obiect:
De asemenea, puteți adăuga compania dvs. în directorul companiilor IT. și să publice articole, știri, posturi vacante și alte informații în numele firmei.
Timp de generare: 0.752