MVC per un'applicazione desktop senza alcun livello di dati

Question

Domanda potrebbe essere difficile (a causa della sua natura o il mio modo di descriverlo), in modo davvero leggere questo prima di rispondere.

Ho questa applicazione per scrivere:
a) applicazione desktop;
b) nessuno strato di dati nel senso di base di dati, file o qualsiasi altro repository (non c'è bisogno di salvare, memorizzare o caricare dati);
c) applicazione avrà alcuni algoritmi di calcolo implementato (algoritmo genetico);
b) fornisce GUI che consente di visualizzare i controlli per app e calcoli risultati.

Sto pensando di usare pattern MVC, ma ho dei dubbi come usarlo. Poiché ho livello dati nel senso di database (ad esempio) (dati viene generato durante l'esecuzione in base all'input dell'utente) Sono preoccupato modo di usare MVC in questa implementazione. Finora ho si avvicinò con due approcci:

1. interfaccia grafica è la vista. GeneticAlgorithm è il controller. GeneticAlgorithmResults è il modello (come classe che solo i dati dei depositi). Flusso di base:

   • The View invia l'input dell'utente al controller;
   • Il controllore elabora input dell'utente e genera dati;
   • il controllore invia i dati generati al Modello;
   • Il Modello notifica al View di nuovi dati;
   • The View tira nuovi dati e aggiorna il display.

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

   • The View invia l'input dell'utente al controller;
   • Il controllore elabora input dell'utente e invia segnali di comando per il modello.
   • aggiorna il modello suo stato interno (genera nuovi dati);
   • Il Modello notifica al controller su nuovi dati;
   • Il controller estrae i dati del modello;
   • Il titolare elabora i dati;
   • Il titolare spinge dati alla View elaborato;
   • The View aggiorna il display.

In primo approccio sembra essere più semplice e più come MVC. Il problema è che una certa logica avrebbe dovuto essere nel Modello - decidere quando notificare il modello come non verranno visualizzati tutti gli aggiornamenti dei dati, o forse display sarà aggiornato con i gruppi di dati non ogni piccolo cambiamento. Tali decisioni saranno basate su input dell'utente. Che cosa è più alcune ulteriori elaborazioni dei dati può essere necessaria prima di visualizzazione attuale. Questo sarebbe in vista.

Il secondo approccio invece sembra essere più complicato e assomiglia a molto i messaggi vengono passati per realizzare il compito. Ma si dà il pieno controllo della logica al controller e separa le responsabilità della View, Controller e il modello (che è lo scopo principale di MVC).

Quale approccio mi consiglia? O forse li dovrei mescolare e utilizzare prima architettura approccio con il flusso di comunicazione secondo approccio? O qualche disegno diverso?

Answer 1

Dalla mia comprensione della MVC, la seconda versione è più come la rigorosa 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 sciolto e non sono necessariamente destinate ad essere seguite alla T.

A mio parere, un mix di entrambi è una buona idea. Se una certa logica finisce nel modello, non è la fine del mondo, significa solo che bisogna essere più attenti a tenere traccia della separazione dei componenti. Se una piccola modifica al MVC rende la vita più facile al 50% (meno un messaggio in testa), allora è probabilmente una buona idea.

Answer 2

avrei sicuramente andare con qualcosa di più vicino alla seconda realizzazione. Sì, lo fa sembrare più messaggi passati avanti e indietro, ma se l'applicazione cresce e cambia, sarete felici che hai costruito l'applicazione con piccole classi.

Si consideri:? Dove è la logica per gestire compiti banali come il passaggio tra gli algoritmi, la loro esecuzione e l'elaborazione dei dati per la visualizzazione

Gli algoritmi genetici operano su un qualche tipo di input o di partenza dei dati, non è vero? Si potrebbe ottenere questo dal vostro strato di accesso ai dati. Non avete bisogno di dati di semi o le condizioni di inizializzazione? Che dire di salvare i risultati di file e il recupero per la successiva revisione? Vorrei pensare che avete bisogno di farlo una volta l'applicazione matura. Aspettiamo che in un primo momento si utilizzerà la persistenza basata su file. Se ti senti fino ad esso, in seguito è possibile aggiornare a un database. Se si codice contro uno strato di persistenza dei dati astratto, non sarà necessario cambiare la logica di business più tardi per sostenere il passaggio da file di database.

Si consiglia di utilizzare il modello di strategia per implementare gli algoritmi. Questo vi permetterà di cambiare l'implementazione del risolutore da algoritmo genetico ai tuoi altri algoritmi senza dover cambiare la logica di business per ogni algoritmo.

Il livello di business vedrà un'ISolver che prende gli ingressi, e si chiamerà mySolver.Solve (). Si dovrebbe essere in grado di passare tra le diverse versioni, senza dover cambiare la logica di business layer ( Aperto chiuso Principle ). L'unica differenza nel modo in cui la logica di business dovrebbe interagire con gli algoritmi dovrebbe essere nel costruttore, e anche lì, si dovrebbe considerare l'utilizzo di un modello di fabbrica.