Esistono motivi negativi per utilizzare una soluzione N-Tier?
-
08-06-2019 - |
Domanda
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.
Soluzione
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!
Altri suggerimenti
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.
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.
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.
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.
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.