Vale la pena usare l'architettura 3-tier per piccole applicazioni (ish)

Question

Sto lavorando su una relativamente piccola applicazione asp.net web e mi chiedo se c'è davvero la necessità di impiegare pieno architettura n-tier. Per un'idea di altezza; ci sono circa 20 le tabelle del database.

In passato ho usato un approccio a 2 livelli in cui la logica di business e l'accesso ai dati sono raggruppati in una singola libreria di classi con era un applicazione web asp.net che formano il livello di interfaccia utente e questo sembrava funzionare bene.

C'è una dimensione di soglia o qualche regola empirica in cui si dovrebbe impiegare n-tier?

Answer 1

Può essere relativamente piccolo, ma ora si fa a pensare che potrebbe crescere in futuro? Del corso bisogna essere pragmatici, ma se si dispone già di separazioni naturali di interesse all'interno del vostro unico assembly allora è abbastanza facile da dividere che in due o più gruppi. Se le classi stesse combinano la logica di business e di accesso ai dati, allora si hanno più lavoro sulle vostre mani. Tuttavia, direi che è quasi più lavoro di scrivere la logica di accesso ai dati in un unico montaggio e la logica di business in un altro, in parallelo, se richiesto, che scrivere tutto in un unico luogo, in primo luogo.

Answer 2

Se si prevede una crescita o di cambiamento di qualsiasi tipo, sarebbe utile a rafforzare i livelli espliciti ora. Ma se questo è il vostro progetto e non vi occupate ponying il costo del cambiamento o il codice strettamente integrato, quindi basta mettere mano a esso come uno strato.

E 'tutta una questione di costi futuri. Nel presente, solo di programmazione, come si va è di gran lunga il più economico, ma non risponde a cambiare molto bene. Con la pianificazione di livello, c'è un costo iniziale, ma è in grado di gestire il cambiamento e strappandogli implementazioni intero livello migliore del primo può avvicinarsi.

Quindi, la regola generale è governato da chi pagherà per il cambiamento e quando.

Answer 3

Sì ne vale la pena. Quello che proponiamo è l'hacking una soluzione insieme. Non posso dirvi quante volte questo mi ha portato dolore e la sofferenza. L'altro lato della medaglia è che gli sviluppatori astronaught overbuild le loro soluzioni. Si vuole evitare questo.

essere semplice, costruire i tre strati, vi consiglio di provare LINQ to SQL, rende la costruzione del DAL un gioco da ragazzi, e quindi è possibile concentrarsi sulla costruzione di una sottile interfaccia utente, ed un BLL che gestirà il sollevamento di carichi pesanti. Non ci vorrà molto più tempo che per farlo e permetterà di unit testing in seguito.

Answer 4

  

C'è una dimensione di soglia o di qualche regola   empirica in cui si dovrebbe impiegare   n-tier?

Non uno che io sappia, ma mi butto questo: se c'è una possibilità questa web app può crescere (o cambiare backend) e / o qualcun altro può finire il suo mantenimento, penso che potrei andare con un approccio a più livelli.

Answer 5

Basta tenere possibile. E 'probabilmente eccessivo, ma ora non scrivere se stessi in una situazione in cui è impossibile. Refactoring su larga scala vi porterà più di ricostruire da zero (e sarà probabilmente proprio questo, ricostruire da zero).

L'ultimo progetto ho lavorato (arrivato in ritardo) è stato scritto in un modo che rompere i livelli era praticamente impossibile. la logica dei dati intreccia con la logica di business intrecciata con logica di presentazione. A breve termine, è stato buono come lo era mai sarà perché fissandola avrebbe preso diversi mesi.

Non è troppo difficile tenere tutto separato così come ho detto prima, basta tenerlo possibile.