Penso che la questione se scegli di affrontare un problema del genere dall'alto verso il basso o dal basso dipende in gran parte da quali principi di progettazione cerchi di andare avanti.
Le maggiori preoccupazioni che nutro dal progetto proposto sono che i livelli di applicazione (ad esempio presentazione / GUI, livello intermedio, database, ecc.) sono confusi. Non c'è nulla di intrinsecamente sbagliato in un approccio a livello singolo alla progettazione delle applicazioni, tuttavia se viene fornita una Requisito Architettonico o un'Assunzione che questa deve essere un'applicazione distribuita a più livelli, il tuo progetto sta già violando questi principi.
Se stai identificando la procedura Database come componente separato in un'architettura orientata ai componenti, ora stai introducendo anche un accoppiamento stretto. Questo tuttavia non sarebbe un accoppiamento stretto se i tuoi componenti sono tutti progettati con l'integrazione verticale in mente. Questa è un'altra ipotesi architettonica che dovrai controllare.
Oltre a ciò, ho già lavorato a progetti di questo tipo prima di utilizzare uno schema di progettazione simile e ho visto personalmente i pro ei contro di questo approccio al design. Secondo la mia onesta opinione, i contro superano i professionisti qui. I professionisti qui sono che le modifiche al layout e ai componenti su uno schermo diventano una modifica dello schema. Se prevedi che i power user avranno la possibilità di personalizzare profondamente i loro schermi, allora è un modello ideale, tuttavia se questo non è il caso, può essere vincolante, specialmente quando i nuovi requisiti dettano specifiche caratteristiche dell'interfaccia utente.
Esamina i framework web basati su componenti come ASP.NET o JSF per vedere se questi potrebbero soddisfare meglio le tue esigenze senza violare MVC o altri principi di architettura.
Modifica
Sembra che le tue esigenze diano effettivamente agli utenti la possibilità di creare i propri schermi e moduli. In questo caso, l'approccio bottom-up è il migliore.
Questo può ancora funzionare con un'architettura multilivello e un modello MVC, ma sarà complicato. Di seguito sono riportati alcuni punti chiave da tenere a mente durante il processo di progettazione:
Il disaccoppiamento
Mantieni i tuoi moduli per lo screen builder separati dalla logica di business di altri domini e dall'accesso ai dati. Mantenere questi disaccoppiati consente all'applicazione di essere più manutenibile e scalabile man mano che vengono aggiunte le funzionalità.
Modello
Il modello in questo caso sarà la logica aziendale dell'applicazione e l'accesso ai dati, nonché qualsiasi entità di modello di dominio che desideri dichiarare. Il modello di generatore di schermo è separato da questo.
Visualizza (Screen Builder MVC e altre viste)
La vista sarà composta dalle pagine di visualizzazione codificate e dall'intero modulo di Screen Builder.
Che cosa significa?
Fondamentalmente la tua vista contiene un design MVC autonomo completamente separato per gli schermi dinamici dell'utente.
- Modello di Screen Builder: l'accesso ai dati alla stored procedure che restituisce i dati sugli elementi dello schermo. Questo è anche il modello di dominio dei dati restituiti.
- Visualizzazione Screen Builder: il codice che genera la vista dinamica generata dall'utente.
- Screen Builder Controller: la stored procedure e altre attività correlate ai controller che riducono il recupero e la conversione del modello e la creazione della vista per l'utente.
Regolatore
Il controller in questo caso sarà il controller del framework dell'applicazione web.
Il seguente modello offre un approccio multilivello disaccoppiato avvicinandosi al design della generazione dinamica della forma come un componente MVC separato che opera all'interno della progettazione MVC basata sul Web dell'intera applicazione.