Come utilizzare lo schema MVP nei sistemi embedded?

3

Sto definendo l'architettura per un sistema embedded dotato di touch screen LCD per interagire con l'utente. Per descrivere il mio problema, posso utilizzare una lavatrice dotata di touch screen LCD come esempio per il mio sistema.

Alcune azioni dell'utente sul display LCD sono semplicemente modifiche dei parametri, come la temperatura di lavaggio, il tipo di ciclo, ecc. Altre azioni dell'utente sul display LCD determinano l'attivazione di una particolare azione. Ad esempio, premendo il pulsante di avvio si avvia l'inizio del ciclo di lavaggio.

Nel processo di definizione dell'architettura del software, sto valutando la possibilità di utilizzare il pattern MVP per implementare l'interazione tra lo schermo LCD touch e il ciclo di lavaggio. Sotto questa ipotesi, la vista è rappresentata dallo schermo LCD touch popolato con vari widget grafici.

Ciò che non mi è chiaro è come mappare Presenter e Model per le mie particolari circostanze.

Da quanto ho capito, il modello comprende sia il comportamento che i dati. Se questo è corretto, credo che nel mio caso il Modello debba essere mappato sia ai dati del ciclo di lavaggio che alla logica del ciclo di lavaggio. Considerando che il ruolo Presente dovrebbe essere quello di coordinare l'evento touch screen LCD, come "Pulsante Start premuto", con il Modello.

La mia interpretazione è corretta?

    
posta Robbo 14.03.2016 - 08:36
fonte

2 risposte

2

Sì, la tua interpretazione è corretta.

Nei modelli MVP, la vista è responsabile per il display (LCD), il modello per la lavatrice effettiva e il livello di presentazione è responsabile per il collegamento dei due insieme.

Questo significa che il livello Presentazione dovrebbe

  • recupera i valori correnti dei parametri per visualizzarli nella vista
  • aggiorna i valori dei parametri se l'utente li ha modificati
  • Il pulsante
  • translate preme sull'interfaccia utente in un'azione per la lavatrice.
risposta data 14.03.2016 - 09:40
fonte
0

Per citare da questa risposta:

ViewModel Presenter projects the data from the Model into a format that fits the View.

Il Model è i dati in un modo che ha senso memorizzare i dati. Il Model conosce lo stato di lavaggio corrente, ha la capacità di avviare / arrestare il lavaggio, può aprire la porta, ecc. Il Modello sta anche decidendo quando si rifiuterà di aprire la porta. Model non sa nulla dell'esistenza di View o Presenter .

La View è la logica della GUI che presenta i dati sullo schermo. Se non c'è Presenter , View conosce la Model e parla direttamente a Model . Se c'è un Presenter , View non sa di Model e parla con Presenter invece di Model .

Il Presenter è il livello di traduzione che ti consente di mantenere il View semplice. Il Presenter , proprio come Model , non conosce il View . Il Presenter non è strettamente necessario: se Model presenta i dati in un formato che è banale da mostrare con View , non c'è bisogno di una traduzione tra loro. Ma nei progetti del mondo reale arriva quasi sempre un punto in cui hai bisogno di un Presenter , perché il Model o il View cambiano rispetto al progetto originale, rendendo la traduzione banale originariamente non banale.

    
risposta data 12.06.2016 - 14:57
fonte

Leggi altre domande sui tag