Esistono motivi negativi per utilizzare una soluzione N-Tier?

Question

Sono abbastanza nuovo nella mia azienda (2 settimane) e stiamo avviando una nuova piattaforma per il nostro sistema utilizzando .NET 3.5 Team Foundation di DotNetNuke.Il nostro "architetto" suggerisce di utilizzare un progetto di classe.Naturalmente, rispondo con un'architettura "a 3 livelli" (progetti aziendali, dati, classi Web).

Ci sono degli svantaggi nell'usare questa architettura?I professionisti sarebbero la separazione del codice dai dati, mantenendo gli oggetti della classe lontani dal codice, ecc.

Answer 1

Immagino che uno svantaggio abbastanza grande sia il volume extra di codice che devi scrivere, gestire e mantenere per a piccolo il progetto potrebbe essere semplicemente eccessivo.

Tutto dipende da ciò che è appropriato per le dimensioni del progetto, la durata prevista del progetto finale e il budget!A volte, anche se fare le cose "correttamente" è allettante, fare qualcosa un po' più "leggero" può essere la giusta decisione commerciale!

Answer 2

tende a richiedere più tempo a un team inesperto per creare 3 livelli. È più codice, quindi più bug.Comunque sto solo facendo l'avvocato del diavolo.

Answer 3

Spingerei forte per l'approccio a livelli N anche se si tratta di un piccolo progetto.Se utilizzi uno strumento ORM come codesmith + nettiers sarai in grado di impostare rapidamente i progetti e sviluppare codice che risolva rapidamente i tuoi problemi aziendali.

Mi uccide quando inizi un nuovo progetto e passi giorni seduti attorno a un filatoio a parlare di come dovrebbe essere architettata l '"architettura".Vuoi dedicare del tempo a risolvere il problema aziendale, non a risolvere i problemi che altre persone hanno risolto per te.Usare un ORM (non importa quale, basta sceglierne uno e attenervisi) per aiutarti a ottenere la trazione iniziale ti aiuterà a rimanere concentrato sugli obiettivi del progetto e non a distrarti cercando di risolvere i problemi di "architettura".

Se, alla fine, l'architetto vuole adottare l'approccio di un unico progetto, non c'è motivo per cui non sia possibile creare una cartella app_code con una cartella BLL e DAL per separare il codice per ora, il che ti aiuterà a passare a un Soluzione a più livelli in seguito.

Answer 4

Perché vuoi il capacità di poter distribuire i livelli su diversi livelli fisici (uso sempre "livello" per fisico e "livello" per logico), dovresti pensarci due volte prima di mettere tutto in una classe perché hai importanti refactoring da fare se o quando è necessario iniziare a distribuire.

Answer 5

Come per qualsiasi cosa, l'astrazione crea complessità, quindi la complessità di eseguire il sistema a N livelli dovrebbe essere adeguatamente giustificata, ad esempio, il sistema a N livelli avvantaggia effettivamente il sistema?Là Volere essere piccoli sistemi che funzioneranno meglio con il livello N, anche se molti di loro non lo faranno.

Inoltre, anche se il tuo sistema è piccolo al momento, potresti voler aggiungere più funzionalità in un secondo momento, senza passare a N livelli Potrebbe costituiscono una sorta di debito tecnico da parte tua, quindi devi stare attento.

Answer 6

L'unico svantaggio è la complessità, ma in realtà quanto è difficile aggiungere alcuni oggetti di dominio e associarli a un elenco di essi invece di utilizzare un set di dati.Non devi nemmeno creare tre progetti separati, puoi semplicemente creare 3 cartelle separate all'interno dell'app Web e assegnare a ciascuna uno spazio dei nomi come YourCompany.YourApp.Domain, YourCompany.YourApp.Data, ecc.

Il grande vantaggio è avere una soluzione più flessibile.Se inizi a scrivere la tua app come un'applicazione incentrata sui dati, accoppiando fortemente le pagine dei moduli Web ai set di dati, finirai per fare molto più lavoro in seguito migrando a un modello più incentrato sul dominio man mano che la logica aziendale diventa più complessa.

Forse a breve termine ti concentri su una soluzione semplice creando oggetti di dominio molto semplici e popolandoli da set di dati, quindi puoi aggiungere loro la logica aziendale secondo necessità e creare un ORM più sofisticato secondo necessità, oppure utilizzare nhibernate.