MVC sono necessari due modelli?

Question

MVC sono necessari due modelli?

#1 da (6 voti)
#2 da (1 voti)

6

Ho fatto software per molto tempo, ma quasi tutto è stato back-end centrico.

Recentemente ho deciso di imparare Swing e ho cercato di applicare i principi MVC. Mi rendo conto che in Swing the View è gestito per te dai componenti che aggiungi alla finestra / frame / pannello, e il controller è il tuo codice che risponde agli eventi. Tuttavia, quando si tratta di Model, ho scoperto rapidamente che avevo bisogno di due modelli. Uno è il modello di back-end che rappresenta l'universo di dati sottostanti. Quel modello è completamente inconsapevole dell'interfaccia utente e del fatto che sia addirittura visualizzato. Il secondo è una versione del modello con attributi aggiuntivi che regolano gli aspetti relativi alla visualizzazione.

Ad esempio, il progetto che ho scelto era uno strumento che rimandava le istanze, gli schemi e le tabelle del database in un'enorme applicazione aziendale contenente 140 istanze db, diverse centinaia di schemi e migliaia di tabelle. A volte, quando guardi un codice sconosciuto, hai un nome di tabella ma trovi l'istanza e lo schema in cui si trova è un lavoro ingrato.

Lo strumento visualizza 3 colonne: Istanza, schema e tabella DB e ogni colonna contiene solo nomi univoci. Quando si fa clic su un nome di tabella (ad esempio) lo schema e le colonne di istanza vengono filtrati mostrando dove si trova la tabella specifica. Facendo clic sul nome dello schema o sul nome dell'istanza si ottiene un comportamento di filtro simile sulle altre due colonne.

Hounmodellodiback-endchecontieneunastrutturaatrelivelli(Instance,Schema,Table)manonèappropriatoperl'interfacciautentechevogliovisualizzare.Quindihounsecondo"modello di visualizzazione" che è stato creato dal modello di back-end e supporta le tre colonne. È qui che memorizzo i flag che indicano quali voci sono visibili in base all'input dell'utente. I due modelli sono significativamente diversi nella struttura e le voci del modello di visualizzazione contengono riferimenti alle voci del modello di backend. In un certo senso le voci del modello di visualizzazione sono adattatori che consentono di gestire le voci del modello di backend in modo appropriato per la visualizzazione.

Non ho trovato riferimenti a questo, ma il mio istinto è che questo deve essere un problema molto comune. Qualcun altro si è imbattuto in questo problema e quali sono i modi di programmazione "accettati" dell'interfaccia utente per raggiungere l'obiettivo?

mvc model

posta Jim Garrison 13.09.2012 - 23:51

fonte

2 risposte

1

Sono d'accordo con pdr sul fatto che questa è una situazione comune - in effetti ho avuto a che fare con esso durante i miei 20 anni di ingegneria del software. Considera il caso semplice di un database gestito e dei suoi utenti. Gli utenti scrivono le query per restituire i set di risultati. I set di risultati sono tabelle, quindi ciascun utente può creare il proprio modello dal modello di dati interno. A un certo punto un utente chiede al DBA: "Puoi aggiungere questa query al db come una vista in modo da poter eseguire query sulla mia astrazione?"

Lo stesso problema si pone con "Segregazione della responsabilità della query di comando" o qualunque schema, diagramma o schema che qualcuno sogna. Non è possibile separare i modelli perché i modelli devono interfacciarsi tra loro. Il fornitore e il consumatore devono parlare una lingua comune.

Secondo la mia esperienza, la flessibilità deve essere architettata da entrambe le parti, vale a dire che deve esserci un meccanismo per il provider di espandere il modello di dati in modo da offrire oggetti composti, viste o una simile struttura di quel tipo a fornire le astrazioni di livello superiore richieste dai clienti. Inoltre, i clienti devono essere in grado di costruire ulteriori astrazioni di livello superiore nel proprio dominio in modo pulito e gestibile. Se queste due strutture non sono progettate nel sistema, i programmatori li escluderanno e il tuo codice base diventerà un incubo, alla fine inutile.

risposta data 14.09.2012 - 07:27

fonte

Leggi altre domande sui tag mvc model

quando introdurre un livello di servizi applicativi in un'applicazione n-tier Perché il modello Flyweight è pratico?

score 6 · Accepted Answer

Questa è una situazione abbastanza comune e la tua scelta di pattern dipende molto dalla circostanza e dalle tue preferenze personali.

Dove non stai semplicemente scrivendo un'applicazione CRUD, puoi avere un modello di dominio che modella il dominio aziendale e un modello di visualizzazione, specifico per l'applicazione, per la visualizzazione e la modifica di tali dati. Alcuni sostengono che anche quando i due modelli hanno lo stesso aspetto, non dovresti esporre il tuo modello di dati direttamente alla vista.

Oppure puoi considerare il dominio per includere non solo i tuoi dati (noti come Fat Models ), in cui caso il modo in cui l'accesso a esso - l'API esposta alla tua applicazione front-end - non deve riguardare il modo in cui lo memorizzi in qualsiasi senso.

Dai anche un'occhiata al pattern correlato chiamato Segregazione di responsabilità della query di comando . Questo si basa sulla teoria che il modello di dati che si utilizza per manipolare i dati è quasi sempre diverso dai modelli di dati che si utilizzano per visualizzare gli stessi dati. Disegna una linea molto netta tra i due e consente di sviluppare i due in modo indipendente.