architettura n-layer design, vale davvero la pena?

Se la tua applicazione ha effettivamente questi livelli separati (presumo UI, BLL e DAL), quindi:

• Puoi scrivere altre interfacce utente (desktop, dispositivi mobili) senza modifiche ad altri livelli
• Puoi apportare modifiche al tuo BLL e non influire sull'interfaccia utente o sul DAL (e con diverse interfacce utente le modifiche avverranno automaticamente)
• È possibile eseguire la migrazione in un archivio dati diverso senza dover modificare l'interfaccia utente o il BLL (quindi, sharding, NOSQL e clustering possono essere opzioni)
• Testare ciascun livello in isolamento è molto più semplice

Se si dispone di una separazione di questo tipo, è possibile ridimensionare i diversi livelli separatamente (è necessario più potere sul bit dell'interfaccia utente) È possibile aggiungere un server Web alla farm Richiede più potenza DB? Shard, cluster o qualsiasi altra cosa ha senso, sebbene normalmente un tale cambiamento richieda di cambiare l'architettura).

Naturalmente, se hai sviluppato un sito che non ha bisogno di questa scala e non avrà bisogno di essere modificato nei modi di cui sopra, allora tale architettura può essere sopra l'ingegneria.

I livelli per il gusto di avere strati è un problema comune. Ho visto un numero di servizi e applicazioni che erano tecnicamente di livello superiore ma che erano molto colpevoli di violare principi come DRY, separazione di preoccupazioni e simili. Ad esempio, ho lavorato con le app con oltre 10 passaggi di creazione dell'oggetto tra l'interfaccia utente e il DB, oltre 30 DLL diverse con funzionalità ridondanti e così via.

Ora, c'è un enorme vantaggio se riesci a separare con successo le preoccupazioni ed evitare il codice ridondante, dipendente e contorto. Rende il programma più facile da testare, migliorare e mantenere. Sarebbe bello se questo fosse fatto più spesso piuttosto che strati di "livello settoriale carico".

I database vengono superati e i fornitori smettono di supportare le versioni precedenti. L'interfaccia utente è obsoleta (è molto difficile supportare la versione precedente di ASP / ASP.net). Ci sono nuovi requisiti per l'interfaccia utente in questi giorni con l'avvento degli smartphone. Se è necessario sostituire uno di questi, non si desidera sostituire tutta la logica aziendale. La logica di business è l'elemento che rischia di durare più a lungo (basti pensare alle applicazioni Cobol di 30 anni che sono ancora in esecuzione!). A un certo punto potresti anche voler orientare l'applicazione e questo sarà più facile se puoi accedere direttamente alla logica di business.

Inoltre, il layering lo rende molto più gestibile e scalabile, ma lo rende anche molto più logicamente strutturato e leggibile. Sai esattamente dove tutto deve andare, e quando torni a farlo, sai dov'è. Ad esempio, ho lavorato su molte applicazioni 'forms over stored procedure' (questa è un'alternativa comune a un'applicazione a più livelli) e trovo la logica aziendale sparsa tra l'interfaccia utente e le stored procedure. Se c'è un BLL, non ci sono scuse per essere in nessun altro posto oltre al BLL (OK, tranne in circostanze eccezionali).

Inoltre, discuto sul fatto che un'applicazione a livello n richiede veramente che molto più sforzo per svilupparsi? Credo che il sovraccarico di sviluppo sia ampiamente ripagato dalla manutenibilità.

Non tutte le applicazioni richiedono un'architettura a livello di n, ma immagino che qualsiasi cosa abbia richiesto un anno di sviluppo sarebbe.