Livelli statici in un'applicazione Web Java

Question

Sto costruendo un piccolo sito Web per divertimento / apprendimento utilizzando un design a livelli abbastanza standard Web / Service / Data Access.

Per salvarmi dal dover costantemente creare istanze del mio livello di servizio / classi di livello di accesso ai dati, ho reso tutti i metodi in esse statici. Non dovrei avere problemi di concorrenza poiché usano variabili locali ecc. E non condividono alcuna risorsa (le cose sono abbastanza semplici per questo al momento).

Per quanto posso vedere l'unico compromesso per questo è che non sto davvero seguendo un vero approccio OO, ma poi mantiene il codice molto più pulito.

C'è qualche motivo per cui questo non sarebbe un approccio praticabile? Che tipo di problemi potrebbero sorgere in seguito? Sarebbe meglio avere una "fabbrica" classe che può restituirmi istanze del servizio e classi del livello dati secondo necessità?

Answer 1

Svantaggi:

• Non sarai in grado di scrivere unit test in quanto non sarai in grado di scrivere dati falsi di accesso / oggetti di logica aziendale su cui eseguire i test.
• Avrai problemi di concorrenza poiché diversi thread tentano di accedere contemporaneamente al codice statico - o se usi metodi statici sincronizzati finirai con i thread in coda per usare i metodi statici.
• Non sarai in grado di utilizzare le variabili di istanza, che diventeranno una restrizione man mano che il codice diventa più complesso.
• Se sarà necessario, sarà più difficile sostituire elementi del livello aziendale o di accesso ai dati.
• Se hai intenzione di scrivere la tua domanda in questo modo, faresti meglio ad usare una lingua progettata per funzionare in questo modo, come PHP.

Faresti meglio ad andare per classi di livello business / data access non statiche:

• Uso del modello singleton (creazione di una singola istanza di ogni classe e condivisione tra i thread) ...
• O creando istanze delle classi in ogni thread come e quando sono necessarie.

Tieni presente che ogni utente / sessione connesso alla tua applicazione verrà eseguito nel proprio thread, quindi la tua applicazione web è intrinsecamente multi-thread.

Answer 2

Conosci quelle giostre al parco dei divertimenti dove dicono "ti preghiamo di tenere sempre le mani e i piedi dentro il giro"? Si scopre che la corsa è molto più divertente se non lo fai. L'unico vero compromesso è che non stai davvero seguendo un vero approccio per tenere sempre le mani e i piedi dentro la corsa.

Il punto è questo: c'è un motivo per cui dovresti seguire un approccio "OO vero", così come c'è un motivo per tenere le mani e i piedi dentro il giro - è molto divertente finché non inizi a sanguinare ovunque.

Answer 3

Il modo in cui lo descrivi, questo non è il " errato " approccio di per sé ma non vedo davvero il problema che stai cercando di evitare. Non puoi semplicemente creare una singola istanza di questi oggetti business all'avvio del server e passarli ai servlet secondo necessità?

Se sei pronto a lanciare OO fuori dalla finestra, potresti voler controllare anche il modello Singleton.

Answer 4

Non vedo davvero il vantaggio del tuo design e ci sono molte cose che potrebbero andare storte. Stai salvando una riga di codice, forse? Ecco alcuni svantaggi del tuo approccio:

• Non è possibile sostituire facilmente le implementazioni della propria logica aziendale
• Non è possibile definire variabili di istanza per facilitare la suddivisione della logica in più metodi
• Il tuo presupposto che non sorgeranno problemi multi-thread è quasi certamente sbagliato
• Non puoi facilmente deriderli per i test

Non vedo davvero che l'omissione di una riga di codice ti stia comprando qualcosa.

In realtà non è un " OO Design " problema, ma più di un'adeguatezza. Perché stai persino usando Java in un modo così procedurale? Sicuramente PHP sarebbe più appropriato per questo tipo di design (e in realtà ti farà risparmiare tempo non dovendo compilare e distribuire).

Vorrei solo rendere il tuo livello aziendale non statico; renderà molto più semplice la gestione, la modifica e l'evoluzione della tua applicazione.

Answer 5

Potresti avere difficoltà a testare l'unità dei tuoi oggetti con questo tipo di architettura. Ad esempio, se si dispone di un livello di oggetti business che fanno riferimento al livello di accesso ai dati statici, potrebbe essere difficile testare il livello aziendale poiché non sarà possibile utilizzare facilmente oggetti di accesso ai dati simulati. Cioè, quando testate il vostro livello aziendale, probabilmente non vorrete usare il "reale" metodi nel livello di accesso ai dati perché apporteranno modifiche indesiderate al database. Se il livello di accesso ai dati non era statico, è possibile fornire oggetti di accesso ai dati fittizi al livello aziendale a scopo di test.

Answer 6

Penso che avrai problemi di concorrenza con tutti i metodi statici con più utenti. Il livello Web escluderà gli utenti simultanei. Tutti i tuoi metodi statici possono gestirlo? Forse, ma non saranno costantemente bloccati nell'accodamento delle richieste in un singolo file? Non sono sicuro, non ho mai provato la tua idea.