Come dovrebbe il mio team decidere tra architetture a 3 e 2 livelli?

Question

La mia squadra sta discutendo la direzione futura in cui prendiamo i nostri progetti. Metà del team crede in una pura architettura a 3 livelli mentre l'altra metà preferisce un'architettura a 2 livelli.

Ipotesi di progetto: le applicazioni aziendali

1. Enterprise logica
2. Affari necessaria tra utente e il database
3. convalida dei dati necessari
4. (service-oriented preferiscono servizi RESTful)
5. Multi -anno piano di manutenzione
6. supportare centinaia di utenti

3-tier della squadra di favori:

1. strato Persistant < ==> strato Domain < ==> strato UI
2. Servizio confine tra strato di almeno persistente e livello dominio. Il livello di dominio potrebbe avere il limite di servizio tra.
3. Traduzioni tra ogni strato (pulita separazione DTO)
4. mano Roll persistenza a meno che non siamo in grado di trovare creativo ed elegante automazione

2-tier della squadra di favori:

1. Entity Framework + WCF Livello Servizio dati < ==> Livello interfaccia utente
2. Logica aziendale mantenuta negli intercettori Servizio dati WCF
3. Conversione minima tra i livelli: favorire la codifica più veloce

Quindi questo è l'argomento di alto livello. Quali considerazioni dovremmo prendere in considerazione? Quali esperienze hai avuto con entrambi gli approcci?

Answer 1

C'è un tempo e un luogo per un design all'avanguardia, e può essere realizzato solo da un architetto esperto che conosce i dettagli del tuo progetto. Per me, se c'è ogni dubbio o se potrebbe andare in entrambi i modi, lo prendo come questo:

1. Inizio piccola (uno strato)
2. Usa interfaccia-driven sviluppo & buona SRP, progettazione agile, ecc
3. Una volta che si ha un funzionamento prototipo, avere una sessione di riprogettazione. La scelta dovrebbe essere molto più chiara.

YMMV.

Answer 2

Non credo che le due parti siano effettivamente così distanti.Mi sembra che l'approccio a 2 livelli stia guardando con maggiore attenzione alla presentazione e desiderando che i servizi facciano il lavoro pesante. I servizi probabilmente avranno un altro livello coinvolto per l'accesso ai dati, quindi è un altro approccio a 3 livelli. È anche quello che preferisco nel mio lavoro perché apportare le modifiche nei servizi spesso non richiede alcuna modifica ai consumatori, presupponendo di mantenere la stessa interfaccia.

Tutto ciò detto, tuttavia, penso che questo dovrebbe essere di gran lunga inferiore nell'elenco delle priorità delle cose di cui preoccuparsi. Un approccio a più livelli non ti aiuterà da solo. È così che sono costruiti quei livelli che è importante. Ritengo che sia molto più importante per tutti essere d'accordo sulle pratiche di codifica. Cose come Iniezione di Dipendenza, Separazione di Preoccupazioni, Inversione di Controllo, Test di Unità, Derisione, ecc. Queste cose sono molto più importanti che preoccuparsi di quanti livelli ci sono. I livelli seguiranno naturalmente una volta che questi saranno a posto.