MVC per app desktop senza livello dati

Question

La domanda potrebbe essere complicata (a causa della sua natura o del mio modo di descriverla), quindi leggi davvero questo prima di rispondere.

Ho questa app per scrivere:
a) app per desktop;
b) nessun livello dati nel senso di database, file o qualsiasi altro repository (non è necessario salvare, memorizzare o caricare dati);
c) l'app avrà implementato alcuni algoritmi di calcolo (Algoritmo genetico);
b) fornisce la GUI che visualizzerà i controlli per i risultati di app e calcoli.

Sto pensando di utilizzare il pattern MVC ma ho dei dubbi su come utilizzarlo. Dal momento che non ho un livello dati nel senso (ad esempio) del database (i dati vengono generati durante l'esecuzione in base all'input dell'utente), sono preoccupato del modo di utilizzare MVC in questa implementazione. Finora mi sono venuti in mente due approcci:

1. GUI è la vista. GeneticAlgorithm è il controller. GeneticAlgorithmResults è il modello (come classe che memorizza solo i dati). Flusso di base:

   • La vista invia l'input dell'utente al controller;
   • Il controller sta elaborando l'input dell'utente e genera dati;
   • Il controller invia i dati generati al modello;
   • Il modello notifica la visualizzazione dei nuovi dati;
   • La vista estrae nuovi dati e aggiorna il display.

2. GUI è la vista. AppEngine è il controller. GeneticAlgorithm nad GeneticAlgorithmResults sono il modello. Ora abbiamo:

   • La vista invia l'input dell'utente al controller;
   • Il controller sta elaborando l'input dell'utente e invia segnali di controllo al modello.
   • Il modello aggiorna il suo stato interno (genera nuovi dati);
   • Il modello notifica al controller i nuovi dati;
   • Il controller estrae i dati sul modello;
   • Il controller elabora i dati;
   • Il controller invia i dati elaborati alla vista;
   • La vista aggiorna il display.

Primo approccio sembra essere più semplice e più come MVC. Il problema è che alcune logiche dovrebbero essere nel modello: decidere quando notificare il modello, poiché non tutti gli aggiornamenti dei dati verranno visualizzati, o forse la visualizzazione verrà aggiornata con i set di dati, non ogni piccola modifica. Queste decisioni saranno basate sull'input dell'utente. Qualche altra elaborazione aggiuntiva dei dati potrebbe essere necessaria prima della visualizzazione effettiva. Questo sarebbe nella vista.

D'altro canto, il secondo approccio sembra essere più complicato e sembra che molti messaggi vengano passati per raggiungere l'obiettivo.Ma dà il controllo completo della logica al controller e separa le responsabilità della vista, del controller e del modello (che è lo scopo principale di MVC).

Quale approccio consiglieresti? O forse dovrei mescolarli e usare l'architettura del primo approccio con il flusso di comunicazione dal secondo approccio? O qualche altro design?

Answer 1

Dalla mia comprensione di MVC, la seconda versione è più simile al paradigma MVC. Tuttavia, uno dei miei insegnanti molto intelligenti una volta mi ha detto che i modelli di progettazione sono lì per dare una serie di linee guida e non devono necessariamente essere seguiti al T.

A mio parere, un mix di entrambi è un buona idea. Se alcune logiche finiscono nel Modello, non è la fine del mondo, significa solo che devi essere più attento a tenere traccia della separazione dei tuoi componenti. Se una piccola modifica a MVC ti rende la vita più semplice del 50% (meno il sovraccarico del messaggio), allora è probabilmente una buona idea.

Answer 2

Mi piacerebbe sicuramente andare con qualcosa di più vicino alla seconda implementazione. Sì, sembra che passino più messaggi avanti e indietro, ma se la tua applicazione cresce e cambia, sarai felice di aver creato l'applicazione con classi piccole.

Considerare: dov'è la logica per gestire attività banali come il passaggio da un algoritmo all'altro, l'esecuzione e l'elaborazione dei dati per la visualizzazione?

Gli algoritmi genetici operano su una sorta di input o di dati di partenza, no? Otterrai questo dal tuo livello di accesso ai dati. Non hai bisogno di dati seme o condizioni di inizializzazione? Che ne dici di salvare i risultati su file e recuperarli per una revisione successiva? Penserei che è necessario farlo una volta che la tua domanda è matura. Aspettatevi che inizialmente userete la persistenza basata su file. Se ti senti all'altezza, in seguito puoi eseguire l'aggiornamento a un database. Se si codifica contro un livello di persistenza dei dati astratti, non sarà necessario modificare la logica aziendale in un secondo momento per supportare la modifica da file a database.

È necessario utilizzare il modello di strategia per implementare i propri algoritmi. Ciò ti consentirà di cambiare l'implementazione del tuo risolutore dall'algoritmo genetico agli altri tuoi algoritmi senza dover modificare la logica di business per ciascun algoritmo.

Il livello aziendale vedrà un ISolver che prende input e chiamerai mySolver.Solve(). Dovresti essere in grado di passare da una versione all'altra senza dover modificare la logica del livello aziendale (Open Closed Principle). L'unica differenza nel modo in cui la logica di business dovrebbe interagire con gli algoritmi dovrebbe essere nel costruttore, e anche lì, dovresti considerare l'utilizzo di un pattern Factory.