Cosa c'è di sbagliato in un progetto MVC standard?

Entrambi Onion Architecture e MVC hanno i loro benefici e le loro conseguenze.

Nessuna architettura è perfetta e ognuna è stata progettata per uno scopo diverso. Non costruire un camion enorme se hai solo bisogno di uno scooter, ma non aspettarti di trasportare 5 tonnellate di scatole con uno scooter.

MVC funziona bene in applicazioni di grandi dimensioni in modo che gli sviluppatori di FE possano concentrarsi sugli sviluppatori View e BE sui controller e sul modello. I modelli possono anche imitare ciò che è memorizzato nel database, il che rende più facile l'implementazione da parte dei DBA. Ci sono molti altri vantaggi di MVC che non approfondirò ora.

Tuttavia la suddivisione ha un costo iniziale da impostare e potrebbe non valerne la pena per un progetto molto piccolo.

The Onion Architecture ha il vantaggio che è relativamente veloce da configurare in modo da vedere i risultati (prototipi) molto più velocemente. Ogni strato dipende dagli strati interni ma non viceversa. Questo ti dà molta flessibilità se devi lavorare sull'intero ambito comunque dall'interfaccia utente ai modelli di dominio. Penso che questo dovrebbe funzionare bene per una piccola squadra, ma non lo consiglierò per una grande squadra o un grande progetto.

Onion Architecture ha un insieme comune di modelli e servizi di dominio che vengono utilizzati da "servizi" esterni in modo da poter aggiungere rapidamente più "servizi" quando richiesto. Tuttavia, se cambi il nucleo della "cipolla" devi cambiare l'intera applicazione in quanto tutto ciò che potrebbe potenzialmente dipendere e utilizzare i servizi di base e penso che sia probabilmente il più grande svantaggio, ma potrebbe essere ok se il progetto è molto piccolo.

Nulla, se lo scopo è seguirlo utilizzando un modello di progettazione a 3 livelli. Molte delle funzionalità gestite da MVC riguardano View (UI), Controller (Business Logic) e Model (Data). Credo che il Modello e il Controller siano intercambiabili per i loro scopi.

In sostanza, il modello gestisce il livello dati, la vista gestisce il livello di presentazione e il controller può gestire il livello aziendale. In genere, se viene seguito, viene anche presa in considerazione la separazione delle preoccupazioni. Penso che se c'è qualche problema con lo standard MVC, è che diventa rapidamente strettamente accoppiato o non scalabile se altri livelli vengono aggiunti senza considerare i tre livelli principali forniti con MVC.

Lo standard sopra indicato non tiene conto della logica aziendale, della logica dell'interfaccia utente, come livelli separati a prima vista. Tuttavia, questo apparentemente si sta prendendo cura del primo progetto, mentre il progetto con i modelli considera il livello dati.

Vedo Cipolla come un buon complemento a MVC e DDD ... Non sono in conflitto, e nella mia mente, non aggiungono qualcosa di troppo complesso al tuo progetto. Un progetto che utilizza solo MVC può essere strettamente accoppiato, l'architettura di cipolla affronta questo problema. E lo stesso progetto MVC può avere un modello disordinato, a cui il DDD si rivolgerebbe.

Seguire questi principi non è importante quanto comprenderli. Se tu e il tuo team li comprendete, saprete quando è opportuno implementarli. Spesso non hai bisogno di un'implementazione rigorosa.

Nella mia esperienza, quando ti concentri ciecamente sui principi, ti dimentichi di KISS.