3 Tier Architecture vs 2 Tier Architecture

Question

Quali sono gli esempi in cui abbiamo davvero bisogno di 3 Tier Architecture? La maggior parte delle applicazioni che utilizzano l'architettura a 3 livelli può essere utilizzata con l'architettura a 2 livelli?

Nota: Sto cercando di vedere il valore di 3 Tier Architettura, mi sento la maggior parte delle applicazioni che ci sono 3 livelli in questo momento può essere fatto in 2 livelli e così Cerco esempi in cui abbiamo assolutamente bisogno di 3 livello e non c'è eccezione a tale necessità.

Answer 1

Suppongo che intenda livelli (unità logiche di separazione) piuttosto che a livelli (unità fisiche di separazione/dispiegamento). Un esempio di un sistema a livelli sarebbe un server web (1 livello) che consegna pagine Web (un altro livello) che attinge i dati da un database al terzo livello).

Il solito obiettivo di un'architettura a più livelli è separare le responsabilità. Questo ha due vantaggi chiave (tra gli altri).

Prima di tutto il tuo progetto sarà più chiaro in quanto le responsabilità non saranno confuse e quindi il codice sarà più facile da leggere, capire e mantenere.

In secondo luogo, è probabile che si riducano le duplicazioni, ad esempio in un'app Web se le pagine gestiscono anche la logica aziendale (o l'accesso ai dati degli orrori degli orrori) oltre a visualizzare le pagine, quindi si può essere certi che più pagine tenteranno di fare le stesse cose o cose simili.

Non c'è bisogno all'architetto (ad esempio in strati, anche se ci sono altri modi) qualsiasi pezzo di software, ma per qualsiasi cosa a parte cose banali il risultato sarà un disastro impossibile da mantenere se non lo fai.

Answer 2

Beh, se si dispone di un sito Web ... Probabilmente si dispone di un codice JavaScript, quindi una volta che si tratta di un livello, si ha la logica aziendale nel server e si dispone del database per memorizzare le cose. Sono tre livelli secondo me. Naturalmente è possibile utilizzare i proc memorizzati nel database e saltare il livello della logica di business in modo che sia possibile creare un sito Web con due livelli se si desidera, ma se non si desidera utilizzare i proc memorizzati si avranno tre livelli.

Answer 3

Puntelli a FinnNk, ma lascia che ti dia un esempio di cosa succede quando non separi i tuoi livelli. Ho lavorato, per anni, su un progetto che è stato gravemente separato alla nascita. Tutti e tre i livelli - di più, se si crede a ciò che ha detto tuinstoel - sono raggruppati in singole pagine JSP. Sono sicuro che all'epoca sembrava una cosa intelligente (più veloce da codificare quando hai appena iniziato) ma questa mostruosità è cresciuta e cresciuta, e nessuno ha avuto il tempo di fare il refactoring.

Ora abbiamo 2000 + pagine JSP, con codice duplicato sparsi ovunque. Fare un cambio di schema richiede un attento backtracking per capire quali pagine potrebbero essere effettuate, e test individuali di ciascuna di quelle pagine. Nessuno nella gestione pensa che sia abbastanza importante passare il tempo per risolvere questo - guadagni a breve termine, perdita a lungo termine.

Do. Non. Partire. Questo. Itinerario.

Separare i livelli porta a un codice migliore, più veloce, più testabile e più modulare. Ti ringrazierai per questo, e (ancora più importante) le persone che verranno dopo te ti ringrazieranno per questo.

Answer 4

Alcuni database espongono un'interfaccia di resto al mondo esterno, ad esempio i database NoSQL CouchDB e RavenDB. Ciò significa che il Javascript in esecuzione nel tuo browser può chiamare il database senza un livello intermedio.

Si veda ad esempio: http://www.infoq.com/news/2010/06/couchdb

"Clean and semplici due tier ben educato/interfaccia REST HTTP e API (html + javascript nel browser + divano + javascript come server)"

Oracle ha un server Web all'interno, è possibile utilizzare proc memorizzati che espongono un'interfaccia resto al mondo esterno. Quindi il JavaScript nel tuo browser può anche chiamare il database Oracle senza un livello intermedio.

Hai sempre hai bisogno di un livello intermedio quando tutto ciò che vuoi è ottenere alcuni dati dal database? Mi pongo questa domanda.

(TTT precedentemente noto come Tuinstoel)

Answer 5

Alcuni casi che possono guidare ci si sposta da 2-tier a 3 livelli: 1- Il sistema dispone di diverse tipologie di clienti (Desktop, Web, Mobile, ecc) 2- Il vostro sistema ha un tipo eterogeneo di origini dati (ad esempio risorse non DB)
3- Il vostro sistema richiede un protocollo di comunicazione client/server specifico 4- Si desidera nascondere e proteggere il livello dati dal client 5- Si necessità di scalabilità per cluster di server e bilanciamento del carico 6- È necessaria l'integrazione da server a server trasparente per il client 7- Yo si desidera utilizzare risorse condivise per il numero di client (ad esempio connessione DB) 8- Si desidera semplificare la manutenzione del sistema disaccoppiando il client dal server db o dal gruppo di server 9- Si desidera mettere la business logic in un livello separato su piattaforma specifica 10- Si desidera ridurre il traffico tra client e DB

Answer 6

Primo, ottima domanda. Come altri hanno notato, entrambi hanno dei meriti. "Separazione di preoccupazione" è il vantaggio principale di 3-tier e che paga i dividendi in diversi modi:

1. Sicurezza: Separando la logica di business dalla presentazione, è possibile applicare politiche più rigorose per i vari strati per esempio i moduli di presentazione senza dati o logica possono essere nella tua zona di presentazione in modo che gli utenti anonimi possano accedere al tuo contenuto "pubblico".
2. Maintainability/gestibilità - molto è già stato detto su questo
3. Riutilizzo/Disaster Recovery: Per instace, se un app di gestione pharamcy può decidere di esporre un'interfaccia utente, nonché servizi che terze parti possono utilizzare per effettuare ordini di prescrizione. Separando la logica di business in un livello separato, è possibile mantenere il servizio/logica indipendentemente dalle UI

ci sono molti altri, ma questi si spera dare un'idea di potenziali benefici