Design Class Diagram con MODELLO MVC

Messaggioda gdembn » 07/11/2019, 16:44

Non riesco a capire una cosa. Ho sviluppato un progetto SW per il quale ho costruito un UML class diagram di relativo al Design,e che faccia capire l'interazione tra VIEW - CONTROLLER - MODEL nel mio sistema SW. Fin qui tutto chiaro. Mi è stato richiesto di rappresentare anche la parte relativa ai dati persistenti nel modello MVC ... Ho pensato quindi di "incrociare" il concetto di MVC con il concetto di PATTERN DAO... attraverso quindi degli appositi Data Access Object nel model, ho "astratto" l'accesso/modifica ai dati ! Sto leggendo in giro su vari forum stranieri, e mi danno pareri abbastanza contrastanti e alcuni dei quali anche scorretti sicuramente! Non so se sia corretto ciò che ho fatto... potreste aiutarmi?



Immagine


Ho collegato gli "Oggetti" del Model a dei DAO ( che implementano i metodi per l'accesso/modifica dei dati) ... garantendo l'accesso ad un DATASOURCE ( la sorgente dei dati) che mi da un RESULT SET come risultato ( sarebbe il risultato della query) .... Ovviamente vorrei capire se la LOGICA è corretta! (MODEL collegato ai DAO)
gdembn
Starting Member
Starting Member
 
Messaggio: 2 di 6
Iscritto il: 10/10/2018, 16:55

Re: Design Class Diagram con MODELLO MVC

Messaggioda apatriarca » 15/11/2019, 00:46

Non mi è prima di tutto chiaro se il software è qualcosa di esistente, di cui il grafico è una rappresentazione grafica, o un design astratto che quindi esiste solo come grafico. Nel primo caso c'è infatti la richiesta aggiuntiva di avere un modello che rispecchi l'effettiva struttura del codice. Nel secondo è solo necessario che segua le regole imposte dal tipo di grafico. Trovo invece abbastanza dannosa l'idea che un design che non segua in modo perfetto le linee guida di paradigmi con MVC o DAO non siano corretti. Un codice può funzionare correttamente anche senza seguire un qualche modello generico di design del software (che a volte è poco adatto al tipo di problemi che si vogliono risolvere). In effetti questo genere di mentalità (progettare il software cercando di adattare pattern esistenti alla propria situazione) porta spesso a pessimi design in pratica. Già solo pensando a qualcosa come MVC si scopre che ogni singola applicazione di tale metodologia è in pratica molto diversa in quello che rientra in ognuna delle tre categorie e a volte non c'è una vera separazione tra alcune di essere (per esempio la libreria Qt ha solo Model e View). Questi paradigmi sono per lo più usati in pratica come documentazione e sono raramente perfetti. Non sono inoltre necessariamente usati a livello di design, ma solo quando si cerca di descrivere la struttura del codice.

Venendo al tuo grafico. I risultati delle query per ogni DAO non dovrebbero essere disgiunti? Quello che chiedi al database per ogni DAO è infatti qualcosa di diverso. Mi sembra che la richiesta possa inoltre essere un po' ambigua. Voleva effettivamente l'introduzione di qualcosa come il tuo pattern DAO o qualcosa come un diagramma ER del database? L'uso di implementare l'accesso ai dati in quel modo è una scelta personale, ma credo che la scelta di includere tali DAO nel modello sia corretta. L'alternativa, nel caso in cui in realtà ci siano più applicazioni (con un diverso modello e visione dei dati) che interagiscono con gli stessi dati è di avere i DAO come entità separate dal modello, con il modello costruito a partire da essi.
apatriarca
Moderatore
Moderatore
 
Messaggio: 5317 di 10435
Iscritto il: 08/12/2008, 20:37
Località: Madrid


Torna a Informatica

Chi c’è in linea

Visitano il forum: Nessuno e 1 ospite