2009-01-31 22 views
7

Sto avviando un nuovo progetto Web Java che utilizza Hibernate e un'architettura MVC standard. Ho appena iniziato a tracciare la struttura dei progetti e, mentre facevo ciò, ho iniziato a guardarmi intorno per vedere se ci fossero degli standard in quest'area, su dove i Controller dovessero andare e in generale il modo migliore per sistemare tutto. Tuttavia non ho trovato alcuna linea guida.Struttura del progetto Web Java Best practice

Così che cosa sono curioso di sapere è

  • È qualcuno a conoscenza di eventuali orientamenti sulle migliori pratiche per il layout di un progetto Java Web?
  • Qualcuno ha una serie particolare di regole rigide che seguono sempre per diversi tipi di progetti?
  • Le persone tendono a suddividere i pacchetti in base ai diversi livelli come presentazione, business e applicazione?

risposta

3

Per continuare la mia risposta precedente, ho molti progetti web. In tutti loro la struttura sotto src è più o meno la stessa. I pacchetti sono approssimativamente separati in 3 livelli logici.

Il primo è il livello di presentazione, come hai detto, per servlet, listener di app e helper.

In secondo luogo, c'è un livello per il modello di ibernazione/livello di accesso db. Il terzo livello per la logica aziendale. Tuttavia, a volte il confine tra questi strati non è chiaro. Se si sta utilizzando la modalità ibernazione per l'accesso db, il modello viene definito dalle classi di ibernazione, quindi li metto nella stessa area degli oggetti dao. Per esempio. com.sample.model contiene gli oggetti dati di ibernazione e com.sample.model.dao trattiene gli oggetti dao.

Se si utilizza il diritto jdbc (di solito con Spring), a volte trovo più conveniente mettere gli oggetti dati più vicino al livello della logica aziendale piuttosto che al livello di accesso db.

(il resto del materiale di solito rientra nel livello aziendale).

2

Innanzitutto, il seguire la struttura convenzionale di un ide popolare, ala Eclipse, Netbeans, ecc In Eclipse, per esempio, tutto è disposto già con WEB-INF e META-INF cartelle, così imballaggio e l'implementazione è facile. Il codice sorgente delle classi (in genere sotto src) viene automaticamente copiato in WEB-INF/classi. Ci sono alcune altre considerazioni:

  1. Se si utilizza MVC, allora è possibile che non c'è bisogno di accedere direttamente agli JSP. In tal caso, mantenere il codice sorgente JSP sotto WEB-INF/jsp, per motivi di sicurezza.
  2. Analogamente, mantenere i file di tag personalizzati sotto WEB-INF/tag.
  3. Mantieni i file javascript nella cartella js, i file css nella cartella di stile, ecc. Tutte le cartelle devono essere allo stesso livello di WEB-INF per simulare una distribuzione reale.
  4. È bene separare il codice in pacchetti in base ai livelli. Ovviamente il tuo Hibernate daos non ha bisogno di essere nello stesso pacchetto dei tuoi servlet.
  5. Se si finisce con troppi servlet nello stesso pacchetto, si consideri il sub-packaging conforme alla funzionalità, ma è bello che abbiano un pacchetto antenato comune - aiuta con la leggibilità.
+0

Preferisco WEB-INF/content o WEB-INF/view, chissà cosa è o potrebbe essere la tecnologia di presentazione ... –

+0

giusto, grazie per averlo indicato. Finché sono memorizzati sotto WEB-INF ... – Yoni

+0

Alcuni buoni punti ci Yoni. Sono comunque interessato alle opinioni delle persone su come in particolare la directory src dovrebbe essere strutturata con i pacchetti, in quanto i servlet dovrebbero essere inseriti in un pacchetto chiamato presentation poiché essi sono principalmente chiamati contenuto JSP. –

6

Dipende davvero dal tuo framework web.

Ad esempio se si utilizza Wicket, file Java e pagine web coesistere nella stessa directory, mentre nella maggior parte degli altri ambiti, pagine (file .jsp o qualsiasi altra cosa è la presentazione del motore) e code-behind roba (file Java) sono completamente separati.

Quindi leggere la documentazione fornita con il framework (Spring MVC, Struts, JSF e.t.c).

Un'altra buona proposta è quella di utilizzare Maven Archetypes per generare uno scheletro per il proprio framework specifico. Alcuni framework web (come Seam) hanno anche il proprio strumento di generazione del codice che pone le basi per il tuo progetto web.

Il mio unico buon suggerimento (che non è menzionato da Yoni) per la directory src è a fare i pacchetti in base alle finalità di business e non in base al tipo/strato

Ciò significa che i pacchetti per

  • com.mycompany.myproject.customers
  • com.mycompany.myproject.departments
  • com.mycompany.myproject.billing
  • com.mycompany.myproject.reports
  • com.mycompany.myproject.admin

e NOT

  • com.mycompany.myproject.entities
  • com.mycompany.myproject.tables
  • com.mycompany.myproject.graphs
  • com.mycompany.myproject.dialogs
  • com.mycompany.myproje ct.servlets

La seconda struttura è troppo generico, tende a risolvere i pacchetti in giro enormi con roba non correlata ed è difficile da mantenere.

+0

@kazanaki Sfortunatamente in questo progetto sto usando semplicemente MVC, nessun framework. Ho già la mia directory src strutturata secondo le regole Maven. Con il layout del pacchetto esegui l'operazione di sottotitolazione nei diversi livelli o esegui semplicemente il drill-down in sotto-scopi. –

+0

I sottopackaggi Mark sono layer. Per l'esempio che do ai clienti ha customers.actions, customers.servlets, customers.entities e.t.c. Ma in un sottoprogetto di progetti davvero grandi possono esserci degli scopi secondari come dici tu. Nessuna risposta corretta lì IMHO – kazanaki

0

Utilizzare il Maven webapp archetype layout.

project 
|-- pom.xml 
`-- src 
    `-- main 
     |-- java 
     `-- webapp 
      |-- WEB-INF 
      | `-- web.xml 
      `-- index.jsp 

ho incluso la cartella java nell'esempio qui, forse era ovvio, ma è stato lasciato fuori nel link qui sopra per qualche ragione.