MVC / P nell'applicazione desktop

1

Sto sviluppando un'applicazione desktop in C # e ho separato diversi livelli in un'architettura MVC-ish.

Come sono passato da GTK # a XWT, solo le visualizzazioni dovevano essere regolate, quindi la separazione dei livelli è stata fatta abbastanza bene.

Poiché XWT non ha un designer di layout, tutto deve essere impostato nel codice, che a sua volta ha portato a un problema di architettura:

Ho un controller per la visualizzazione di prese, ingressi e connessioni.

Questo controller invia i dati a una vista (evidenziata in rosso). A sua volta, questa vista ha sottoview (verde e blu), che comunicano solo con la vista in rosso.

Durante lo scorrimento / compressione / espansione delle immagini ad albero, la vista verde invia eventi, che vengono ricevuti dalla vista rossa, che a sua volta attiva il ridisegno nella vista blu.

Il controller non vede le viste verdi o blu, ogni cambio di connessioni / prese / prese viene inviato solo alla vista rossa.

Il mio problema: poiché capisco MVC, le visualizzazioni non dovrebbero avere molta logica. Ma le viste verdi sono una classe di 300 linee, la classe della vista rossa ha 200 linee, che è troppe.

Quale problema architettonico può sorgere da questo? Sto trascurando un errore nella mia logica MVC?

    
posta Residuum 16.07.2014 - 23:07
fonte

2 risposte

4

Il modello di progettazione MVC era stato originariamente formulato nei vecchi tempi in cui MS-DOS era ancora un OS dominante. A quei tempi il sistema operativo supportava pochissimo le interfacce grafiche, quindi dovevi fare la maggior parte di te stesso. Nel MVC originale, il compito del Controller era capire quale campo di immissione del testo era attivo e cosa significava se l'utente preme un tasto.

Nei moderni sistemi operativi desktop con display manager e widget completi di funzionalità, il ruolo di Controller è stato effettivamente unito ai componenti View e al controller MVC è stato assegnato un ruolo di coordinamento di livello superiore.

La logica nelle viste dovrebbe essere effettivamente limitata, ma dovrebbe essere limitata alla logica relativa all'interfaccia utente. Per una vista complessa come la tua, anche la logica relativa all'interfaccia utente può essere piuttosto significativa, quindi non vedo alcun problema con la tua architettura.

    
risposta data 17.07.2014 - 08:59
fonte
2

Semplicemente, penso che MVC non sia un ottimo modo per progettare un'applicazione desktop in C #. (dato C # E applicazione desktop che implica che dot net framework compreso wpf è permesso).

Il modo più apprezzato e migliore per progettare un'interfaccia utente desktop in C # è il pattern MVVM.

MVVM, il che significa che Model-View-ViewModel ha il supporto più diretto dalle funzionalità di C # UI e tutto sembra essere fatto solo per MVVM.

La struttura è leggermente diversa da MVC. Non c'è parte del controller. (Il controller nel senso di MVC in precedenza era solo un modo di gestire, ad esempio, eventi di input dell'utente)

In MVVM hai un'architettura a tre strati

Hai un Modello (oggetti di dominio, accesso al database, modello di repository, ...)

ViewModel (una sorta di mediatore tra vista e modello, gestione dell'elemento selezionato, traduzione di testo, ...)

Visualizza (questo è solo ciò che l'utente vede e nient'altro, nessuna logica qui eccetto la semplice conversione al formato desiderato dall'utente di stringhe ecc.)

Si prega di investigare su MVVM. C'è un video fantastico che mostra le tecniche di base di Jason Dollinger su lab49, che può essere trovato qui . Vale sempre la pena investire per un'ora.

    
risposta data 16.07.2014 - 23:17
fonte

Leggi altre domande sui tag