Structura pachetului pentru un proiect Java? (Programare, Java, Pachete)

mawaldne a intrebat.

Care este cea mai bună practică pentru configurarea structurilor de pachete într-o aplicație web Java?

Cum ați configura src-ul, codul de testare a unității, etc.?

7 răspunsuri
johnstok

Ați putea urma instrucțiunile de la maven aspectul standard al proiectului maven. Nu trebuie să folosiți de fapt maven, dar ar face tranziția mai ușoară în viitor (dacă este necesar). În plus, ceilalți dezvoltatori vor fi obișnuiți să vadă acest layout, deoarece multe proiecte open source sunt aranjate în acest fel,

Comentarii

  • De asemenea, vă recomand să folosiți aspectul Maven dacă aveți de ales. Este o structură bine gândită, care a fost testată în luptă și este cunoscută de mulți dezvoltatori. –  > Por Dov Wasserman.
  • 15

  • Puteți utiliza acest oneliner pentru a crea aspectul directorului: mkdir -p src/{main/{java,resources,filters,assembly,config,webapp},test/{java,resources,filters},site} –  > Por Daniel Hepper.
  • Dispunerea standard a proiectului Maven este urâtă… :/ – –  > Por Yousha Aleayoub.
  • @YoushaAleayoub nu trebuie să te căsătorești cu el –  > Por Ashvin Sharma.
lycono

Există câteva resurse existente pe care le puteți verifica:

  1. Împachetați în mod corespunzător clasele Java
  2. Arhitectura Spring 2.5
  3. Tutorial Java – Numirea unui pachet
  4. Convenții de denumire SUN

Pentru ceea ce merită, orientările mele personale pe care tind să le folosesc sunt următoarele:

  1. Începeți cu domeniul invers, de exemplu „com.mycompany”.
  2. Utilizați numele produsului, de exemplu „myproduct”. În unele cazuri, am tendința de a avea pachete comune care nu aparțin unui anumit produs. Acestea ar sfârși prin a fi clasificate în funcție de funcționalitatea acestor clase comune, de exemplu „io”, „util”, „ui”, etc.
  3. După aceasta, devine mai mult o formă liberă. De obicei, grupez în funcție de proiect, de domeniul de funcționalitate, de implementare etc. De exemplu, aș putea avea „project1”, „project2”, „ui”, „client” etc.

Alte câteva puncte:

  1. În proiectele la care am lucrat, este destul de frecvent ca numele pachetelor să decurgă din documentația de proiectare. De obicei, produsele sunt deja separate în zone de funcționalitate sau scop.
  2. Nu vă stresați prea mult cu privire la împingerea imediată a funcționalităților comune în pachete superioare. Așteptați să existe o necesitate între proiecte, produse etc. și apoi refactorizați.
  3. Fiți atenți la dependențele dintre pachete. Nu sunt toate rele, dar pot însemna un cuplaj strâns între ceea ce ar putea fi unități separate. Există instrumente care vă pot ajuta să țineți evidența acestui aspect.

Comentarii

  • În cazul domeniului inversat („com.mycompany”), pachetul „com” este de obicei gol, cu excepția subpachetului „mycompany”? –  > Por Alex Parker.
dataAnalyst

V-aș sugera să vă creați structura pachetelor în funcție de caracteristici, și nu în funcție de stratul de implementare. Un articol bun în acest sens este Practicile Java: Pachet după caracteristici, nu după strat

Comentarii

  • Mulțumiri. Aceasta este ceea ce căutam pentru a transmite gândurile mele echipei –  > Por Pranalee.
  • Și dacă doriți să schimbați bazele de date? Trebuie doar să căutați în 30 de pachete diferite. Treceți de la SFTP la servicii web? Din nou, trebuie doar să căutați în 30 de locuri diferite. Categoric nu sunt un fan. –  > Por SamuelKDavis.
  • un alt exemplu în care împachetarea în funcție de strat prezintă avantaje: dacă serializați clasele în JSON (de exemplu, cu gson), dacă aceste clase sunt ofuscate (de exemplu, de Proguard), (de)serializarea va eșua; trebuie să configurați Proguard să nu se atingă de astfel de clase – cel mai simplu este să specificați un singur pachet cu toate clasele – -.  > Por jmuet.
user5425586

De obicei, îmi place să am următoarele:

  • bin (Binaries)
  • doc (Documente)
  • inf (Informații)
  • lib (Biblioteci)
  • res (Resurse)
  • src (Sursa)
  • tst (Test)

Acestea pot fi considerate neconvenționale, dar mie mi se pare un mod foarte frumos de a organiza lucrurile.

Comentarii

  • „Acestea pot fi considerate neconvenționale” Sunt de fapt neconvenționale și rele de altfel … –  > Por mahieddine.
  • @mahieddine De ce le consideri rele? –  > Por Thomas Johannesmeyer.
  • Ei bine, nu am fost eu cel care a afirmat asta, dar iată câteva dintre gândurile mele: Clasele dvs. de testare sunt cod sursă, astfel încât directorul „tst” (majoritatea oamenilor nu abreviază test btw) ar trebui să fie un subdirector al src (de exemplu, „src” devine „src/main” și „tst” devine „src/test”). De asemenea, „inf” pare să includă conținut care ar putea fi în „doc”. –  > Por Nico Wawrzyniak.
Raj
The way I usually organise is
- src
        - main
                - java
                - groovy
                - resources
        - test
                - java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc

pdeva

Modul în care am, de obicei, ierarhia de dosare…

  • Numele proiectului
    • src
    • bin
    • tests
    • libs
    • docs

Deepak Patankar

O altă modalitate este de a separa API-urile, serviciile și entitățile în pachete diferite.