Un'architettura di livello 3 (fisica) è inefficiente?

Question

Nota: quando faccio riferimento al livello, intendo un livello fisico. Molte delle domande su questo sito relative ai "livelli" si riferiscono a livelli logici, che non è quello che sto chiedendo.

Sto progettando un'app utilizzando un'architettura standard a "3 livelli", con livelli di presentazione, business logic (BLL) e accesso ai dati (DAL). La tecnologia è WPF, C#, LINQ e SQL Server 2008. La mia domanda riguarda l'architettura fisica di questa app.

Posso posizionare il BLL/DAL in una DLL standard che viene caricata ed eseguita sul computer dell'utente, creando un'architettura a 2 livelli: client e server di database. Ma non è troppo difficile trasformare BLL/DAL in un servizio WCF che si trova su un app server e viene chiamato dal computer dell'utente. Questo mi darebbe un'architettura a 3 livelli: client, server delle applicazioni e server di database.

La mia domanda è questa: qual è il vantaggio dell'utilizzo di un'architettura a 3 livelli? Mi è stato spesso detto che i 3 livelli aggiungono scalabilità, ma non mi è immediatamente chiaro il motivo per cui questo sarebbe. E sicuramente stai andando a fare un colpo di performance con gli stessi dati che devono fare due hop sul filo - dal server di database al server di app, quindi dal server di app al computer client.

Apprezzerei il consiglio di architetti e sviluppatori esperti là fuori.

Answer 1

Dipende dall'utilizzo dell'applicazione e dalle esigenze di sicurezza. Se la tua applicazione viene utilizzata su Internet e stai memorizzando qualcosa che è potenzialmente sensibile in qualsiasi modo, si consiglia vivamente di aggiungere la rimozione fisica per il database. Mai e poi mai lasciare nessuno dall'esterno su qualsiasi macchina con accesso diretto al tuo database. Le persone possono tentare di infrangere la tua sicurezza senza una ragione migliore di quella che non hanno niente di meglio da fare.

Anche la scalabilità può essere un fattore, sia di fronte al livello di presentazione (di fronte ai server Web) che nel database. Posizionando un servizio di bilanciamento del carico di fronte al livello di presentazione, le richieste in ingresso possono essere indirizzate a un array di macchine che possono essere gestite in modo indipendente. Le macchine possono essere aggiunte alla piscina nei momenti di necessità e rimosse per la manutenzione. Posizionare gli equilibratori di carico tra gli altri strati può avere lo stesso impatto. L'idea è di fornire un ambiente back-end flessibile e dinamico che possa essere regolato come richiesto dalla domanda.

Answer 2

Può essere. Dipende da cosa è stato implementato e come.

La forza trainante per la creazione di un'architettura fisica a 3 livelli non è necessariamente legata alle prestazioni.

Il motivo per cui viene citata la scalabilità è che un servizio potrebbe essere eseguito su una server farm, ma i client non ne sono a conoscenza. La dimensione della server farm può essere aumentata per soddisfare la domanda se l'architettura è stata progettata per supportarla.

Answer 3

L'inefficienza è negli occhi di chi guarda.

Ad esempio, avere tutto ciò che accade sul client può aumentare l'ingombro della memoria oi requisiti CPU/rete dei computer client. Se questo lavoro può essere scaricato in un server/server farm, è possibile risparmiare il dover eseguire aggiornamenti hardware dei PC client solo per eseguire il software. Se sono necessarie più risorse o aggiornamenti, è possibile aggiungerli/completarli nel livello della logica aziendale senza influire sui client.

Inoltre, la logica di business sul proprio livello può essere più efficiente in seguito (dal punto di vista dello sviluppo del software) quando è necessario esporre alcune funzionalità dell'applicazione in un sistema basato su Web o un componente aggiuntivo di Outlook, o un'app per iPhone.Non si desidera dover aggiornare tutti questi sistemi ogni volta che la logica di business cambia leggermente.

La sicurezza può essere migliore in quanto gli utenti non hanno bisogno dell'accesso diretto al server del database, sono isolati dal server delle applicazioni.

Ti costringe anche a pensare alla tua applicazione in modo modulare con interfacce ben definite che possono avere vantaggi architettonici per il design della tua applicazione.

Answer 4

Ogni volta che ti ritrovi a fare la domanda "X è inefficiente?" si deve, immediatamente, porsi tre domande: precursori

1. Con il termine "inefficiente", quale risorsa pensi che dovrebbe essere utilizzato in modo efficiente e non può essere? Tempo? Spazio? Larghezza di banda? Ore di sviluppo?

2. Perché ti interessa? No, sul serio: se hai intenzione di passare anche solo un minuto a rispondere a questa domanda, ci deve essere una ragione. Qual è questa ragione?

3. Rispetto a cosa?

Per quanto riguarda i suoi commenti su scalabilità è interessato: Per un certo periodo, ho avuto la triste responsabilità di mantenere un sistema il cui architetto che era stato detto che riducendo al minimo andata e ritorno al database farebbe un'applicazione scalabile. Prese quell'intuizione e corse con esso. Puoi leggere su questo progetto here. Mi viene in mente che avrei dovuto dire che in nessun momento durante l'intera decade più lunga di questa applicazione ci sono stati più di quattro utenti che hanno effettuato l'accesso simultaneamente.

Answer 5

Il vantaggio principale delle applicazioni 3t descritte come si faceva non è la scalabilità. Manutenibilità forse.

Per rendere scalabile la tua architettura, hai bisogno di un'altra tecnologia che non hai menzionato. - hai bisogno di servizi. Suggerirei WCF.

Fare il vostro servizio BLL WCF (o più servizi) renderebbe la vostra applicazione molto più efficiente e scalabile, consentendo alla vostra BLL di funzionare su macchine diverse/multiple.