Framework in cui le viste sono definite nel database - difetto di progettazione o ragionevole?

Se il tuo attuale requisito software è che le visualizzazioni siano personalizzabili dal cliente, quindi memorizzare le definizioni di visualizzazione nel database non è affatto un approccio irragionevole.

Penso che scoprirete che il design convenzionale del Model-View-Controller si rompe quando il vostro requisito è la personalizzazione dell'utente, per tutti tranne che per gli scenari più semplici. Di conseguenza, convertire la tua applicazione in un design più ortodosso sarà un esercizio di frustrazione, a meno che tu non valuti attentamente i pro e i contro.

Immagino una sorta di sistema ibrido in cui l'SQL e le viste sono generate dinamicamente, in modo che solo le informazioni richieste siano passate attraverso il filo. Puoi anche utilizzare una sorta di sistema di template Javascript nel browser. Ma non assomiglierà ad un sistema MVC convenzionale, perché MVC è progettato per aiutare il programmatore, non l'utente.

In un mondo perfetto, le tue visualizzazioni personalizzate sono limitate a una piccola parte del sistema e la maggior parte dell'applicazione è effettivamente "cablata". In altre parole, non genererai personalizzati tutti i tuoi punti di vista, ma solo alcuni di essi, lasciando le viste più ortodosse nelle mani capaci di MVC e generando le viste personalizzate solo se necessario.

Posso immaginare una rappresentazione della vista basata su database che consente di modificare le viste in modo dinamico, senza ricompilazione di alcun codice. Se questo è il tuo caso, sospetto che il design abbia qualche merito.

Se il codice Java ha bisogno di per essere aggiornato quando i dati che descrivono una vista nel DB sono cambiati, non penso che il design sia buono; la descrizione è meglio essere contenuta nel codice.

In ogni caso, "un sacco di SQL incorporato" suona abbastanza male. Penserei a una specie di ORM.

Prendi in considerazione la pratica del framework di definire la vista nel database e il controller nel codice come sound design o qualcosa che dovrebbe essere indirizzato?

Ritengo che la memorizzazione di informazioni specifiche dell'utente nel livello dati sia un eccellente principio di progettazione ed è perfettamente compatibile con le buone pratiche di programmazione. Soprattutto se al pubblico previsto verrà fornito uno strumento, anche se solo SQL, per gestire le loro "viste".

Detto questo, sono d'accordo sul fatto che do abbia un problema, sebbene sia più astratto di quello che hai affermato. Il tuo framework deve avere un modo chiaro e ragionevole per gestire scelte utente inaspettate.

Se pensi che la situazione debba essere affrontata, il mio piano a lungo termine sembra ragionevole?

Se causa problemi, dovrebbe essere sicuramente risolto. Ma il piano appropriato dipende da quale sia l'effettivo problema , piuttosto che dal problema che hai identificato.

1. Se il problema è come il vostro sito si comporta se il database non è come previsto , si dovrebbe includere i test e le eccezioni in tal senso nel vostro strato di dati di Java, e assicuratevi di avere un programma di costruzione di database, scritto in Java o qualsiasi altra cosa, in grado di creare le viste e le tabelle necessarie nel database di destinazione.

2. Se il problema è utenti che creano visualizzazioni non valide , dovresti considerare se è possibile fornire un comportamento predefinito nel tuo sito. E 'difficile essere precisi senza sapere se i vostri "punti di vista" sono viste del database oi risultati di query di database, ma o la gestione di SQL standard di colonna-tipi o limitare "sul campo" righe a una lista di "tipi di campo" dovrebbe essere parte del quadro di design. (Omettere con garbo un campo non valido non è una soluzione terribile, per favore.)

3. Se il tuo problema è codice SQL in Java , potresti non avere alcun problema. Tale codice dovrebbe essere spostato su una classe di connessione database dedicata come parte del refactoring, ma la scelta tra una stringa SQL generata da Java e una stored procedure di database è un dettaglio di implementazione, e si dovrebbe solo correre il rischio di spostarsi da l'uno per l'altro se si ha una chiara aspettativa di aumento delle prestazioni.

4. Infine, se il tuo problema è difficoltà o ritardi nella creazione di nuove pagine , dovresti valutare il processo di creazione di queste pagine. Se la maggior parte del lavoro non viene effettivamente svolto dalla tua base di utenti, ma viene svolto dal tuo team Java, lo spostamento del codice necessario in Java potrebbe avere senso. Soprattutto se il tuo team di Java non ha familiarità con SQL.

Come ho detto sopra, è difficile diagnosticare l'adeguatezza di una linea di condotta senza conoscere le specifiche del framework in questione. Tutto il software, in particolare i framework applicativi, è un mezzo per un fine e uno spostamento della complessità dal tempo di esecuzione al tempo di progettazione. Gli aspetti specifici di un corso appropriato sono influenzati molto più da "cosa stai cercando di fare" che "cosa dovrebbe essere fatto".