Care este "cea mai bună practică" pentru primul proiect Java EE Spring?

Deși au fost ani de când am folosit primăvara și nu pot spune că sunt un fan al acesteia, știu că instrumentul App Fuse ( https://java.net/projects/appfuse/ ) a fost de ajutor pentru a ajuta oamenii să bootstrap în termeni de generare a tuturor artefactelor de care aveți nevoie pentru a merge.

De asemenea, primăvara este foarte mult despre testarea unităților și, prin urmare, testabilitatea clasei dvs. Aceasta înseamnă în principiu gândirea despre modularizare, separarea preocupărilor, referirea unei clase prin interfețe etc.

De fapt, mi-a placut foarte bine primavara. A fost o briza proaspata de aer in J2EE Java Beans mediu.

Vă recomandăm să implementați exemplul Primăvara oferă:

http://static.springframework.org/docs/Spring-MVC -Pas cu pas/

De asemenea, am decis sa merg complet si am adaugat Hibernate la aplicatia mea de primavara;), pentru ca Spring ofera suport excelent pentru Hibernate ... :)

Nu am totusi un lucru pe care l-am invatat in modul greu (produs in productie) ... Daca implementati doar interfata Controller si returnati un obiect ModelAndView cu unele date furnizate cu interfata, Spring obtine garbadge resurse, pentru că încearcă să stocheze aceste date în memoria cache. Așadar, aveți grijă să puneți date mari în acele obiecte ModelAndView, deoarece acestea vor înghiți memoria serverului atâta timp cât serverul este în aer de îndată ce pagina a fost vizualizată ...

Concentrați-vă mai întâi pe inima primăverii: Injecția dependenței. Odata ce vedeti toate modalitatile in care DI poate fi folosit, atunci incepeti sa va ganditi la piesele mai interesante cum ar fi AOP, Remoting, Template-uri JDBC etc. Deci cel mai bun sfat este sa lasati folosirea primavara sa iasa din nucleu.

Cea mai buna practica? Dacă utilizați configurația standard XML, gestionați dimensiunea fișierelor individuale și comentați-le în mod judicios. S-ar putea să vă credeți că voi și ceilalți veți înțelege perfect definițiile dvs. de fasole, dar, în practică, este mai greu să vă întoarceți decât codul java simplu vechi.

Mult noroc!

Start here - I actually think it's among the best Software Dev books that I've read.
Expert Spring MVC And Web Flow

Aflați noua configurație bazată pe adnotări pentru clasele MVC. Aceasta face parte din Primăvara 2.5. Folosind clasele bazate pe adnotări se va face scrierea unității de testare un heck de mult mai ușor. De asemenea, posibilitatea de a reduce cantitatea de xml este un lucru bun.

Oh yeah Unitate de testare - dacă utilizați Primăvara, vă mai bine să fie unitatea de testare. :) Scrieți testele unității pentru toate clasele Web și Service Layer.

Citiți designul pe domenii. Faptul că puteți utiliza clase de domenii de obiecte la toate nivelurile unei aplicații de primăvară înseamnă că veți avea un model de domeniu foarte puternic. Folosiți-l.

Cu toate acestea, atunci când utilizați clasele Obiect de domenii pentru populația formelor, veți dori să luați aminte de preocupările recente legate de securitate din cadrul Cadrului de primăvară. O discuție pe partea de server dezvăluie modalitatea de a închide gaura în comentariile.

O modalitate bună de a începe este să vă concentrați pe "Cadrul de primăvară". Portofoliul de primăvară a crescut într-o grămadă de proiecte în jurul diferitelor aspecte ale Enterprise Software. Stick la nucleu la început și încercați să înțelegeți conceptele. Descărcați cele mai recente fișiere binare și verificați exemplul petline al primăverii odată ce vă familiarizați cu nucleul. Oferă o imagine de ansamblu destul de bună a diferitelor proiecte pe care SpringSource le oferă.

Deși documentația este foarte bună, aș recomanda o carte după ce înțelegeți conceptele de bază. Ceea ce am găsit problematică cu documentația este că nu este în profunzime și nu vă poate oferi toate detaliile de care aveți nevoie.

Odată cu lansarea primelor de primăvară 2.5 și 3.0, cred că una dintre cele mai importante bune practici pentru a profita de acum sunt adnotările de primăvară. Adnotările pentru Controlere, Servicii și Depozite vă pot economisi o tona de timp, vă permit să vă concentrați asupra logicii de afaceri a aplicației dvs. și vă poate permite să vă faceți obiectul obiect obișnuit Java (POJOs).

"... ce tehnologie ați folosit imediat: AOP, Hibernate complex ..." - Aș spune că o întrebare mai bună ar fi să întrebați ce oamenii nu au folosit imediat. Aș adăuga exemplele pe care le citezi în lista respectivă.

Modelul MVC de primăvară și modelul JDBC ar fi recomandările mele inițiale. Poți să te duci foarte mult doar cu astea.

Recomandarea mea ar fi să urmez fidel recomandările de arhitectură de primăvară. Utilizați ideile lor de stratificare. Asigurați-vă că stratul dvs. web este complet detașabil de restul. Faceți acest lucru lăsând layerul web să interacționeze cu partea din spate numai prin stratul de serviciu.

Dacă doriți să reutilizați acest nivel de serviciu, o recomandare bună este să o expuneți utilizând serviciile de primăvară "contract first". Dacă începeți cu mesajele xml pe care le transmiteți înainte și înapoi, clientul și serverul dvs. pot fi complet decuplate.

IDE-ul cu cel mai bun suport de primăvară este IntelliJ. Merită să cheltuiți câțiva dolari.

Mai întâi de toate, primăvara este despre modularitate și funcționează cel mai bine dacă se concentrează pe scrierea de componente mici care fac un lucru și o fac bine.

Dacă urmați cele mai bune practici în general, cum ar fi:

• Definirea unei interfețe mai degrabă decât a unor clase abstracte
• Efectuarea de tipuri imuabile
• Păstrați dependențele cât mai puține posibil pentru o singură clasă.
• Fiecare clasă ar trebui să facă un lucru și să o facă bine. Clasele mari de monolit suge, sunt greu de testat și greu de folosit.

Dacă componentele dvs. sunt mici și urmați dogmele de mai sus, acestea ar trebui să fie ușor de sârmă și să se joace cu alte lucruri. Punctele de mai sus sunt în mod firesc, de asemenea, valabile și pentru cadrul de primăvară.

PS

Nu ascultați punctele de mai sus, vorbesc despre cum să faceți totul. Este mai important să înveți cum să gândești decât să faci ceva. Oamenii pot gândi, repetând ceva nu este inteligent, gândirea este.

Dacă doriți doar să faceți o scurgere și să vedeți dacă vă place, vă recomandăm să începeți cu stratul DAO, utilizând suportul JDBC și/sau Hibernate de primăvară. Acest lucru vă va expune la multe concepte de bază, dar faceți acest lucru într-un mod ușor de izolat de restul aplicației dvs. Acesta este traseul pe care l-am urmat și a fost o bună încălzire înainte de a începe să construiesc o aplicație completă cu Spring.

Sfat mic - mi-a fost util să modularizez și să etichetez în mod clar fișierele mele de primăvară xml bazate pe preocuparea aplicației. Iată un exemplu pentru o aplicație web pe care am lucrat:

• MyProject/src/main/resources/spring /
  • datasource.xml - My single data source bean.
  • persistence.xml - My DAOs/Repositories. Depends on datasource.xml beans.
  • services.xml - Service layer implementations. These are usually the beans to which I apply transactionality using AOP. Depends on persistence.xml beans.
  • controllers.xml - My Spring MVC controllers. Depends on services.xml beans.
  • views.xml - My view implementations.

Această listă nu este nici perfectă, nici exhaustivă, dar sper că ilustrează acest lucru. Alegeți orice strategie de numire și granularitate funcționează cel mai bine pentru dvs.

În experiența mea (limitată), am văzut această abordare în ceea ce privește următoarele beneficii:

Arhitectură mai clară

În mod evident, fișierele cu nume de context le oferă celor care nu cunosc structura proiectului un model rezonabil loc pentru a începe căutarea definițiilor fasolei. Poate face ușor detectarea dependențelor circulare/nedorite.

Ajută la proiectarea domeniului

Dacă doriți să adăugați o definiție a fasolei, dar nu se potrivește bine în niciunul din fișierele dvs. de context, poate că există un nou concept sau o preocupare care apare? Exemple:

• Să presupunem că doriți să faceți ca stratul dvs. de servicii să fie tranzacțional cu AOP. Adăugați aceste definiții pentru fasole la services.xml sau le puneți în propriul lor transactionPolicy.xml ? Vorbeste-o cu echipa ta. Politica dvs. de tranzacții ar trebui să fie conectabilă?
• Adăugați fasolea Acegi/Spring Security în fișierul controllers.xml sau creați un fișier de context security.xml ? Aveți cerințe de securitate diferite pentru implementări/medii diferite?

Testarea integrării

Pentru a testa baza de date aveți nevoie să creați numai datasource.xml și persistence.xml pentru un subset al aplicației dvs. pentru testarea integrării (ex: fasole).

În mod specific, puteți adnota o clasă de testare a integrării ca atare:

@ContextConfiguration(locations = { "/spring/datasource.xml" , "/spring/persistence.xml" })

Funcționează bine cu Bean Graph de la IDE de primăvară

Având o mulțime de fișiere de context concentrate și bine-numite face ușor de a crea personalizate BeansConfigSets pentru a vizualiza straturile de aplicația dvs. folosind Spring IDE Bean Graph . Am folosit acest lucru înainte pentru a oferi membrilor echipei noi o imagine de ansamblu la nivel înalt a organizației aplicației noastre.