Commuta l'applicazione complessa di WinForms su MVVM di WPF

0

Questa domanda è collegata alla mia domanda precedente C # Application GUI design dependent sulla configurazione .

I have built quite big WinForms application working in industry for a few years. It communicates with many HW devices. Application can be configured to use or not use some of these devices and GUI is modified by this configuration. Now, even more devices (and application possible configurations) are going to be added, so I need to refactor whole application, maybe even write the most of it again and it will be very painful work as it was generally my the first bigger project.

Infine, ho deciso di iniziare a studiare WPF e ho intenzione di riscrivere nuovamente questa applicazione utilizzando WPF, in parte perché ritengo che un'applicazione WinForms così complessa non sia facilmente estensibile e gestibile, in parte perché voglio comunque imparare WPF in il futuro.

Voglio usarlo correttamente e separare la logica aziendale dall'interfaccia utente. Mi sono imbattuto in alcuni tutorial MVVM usando WPF, ma sono tutti molto semplici. La mia applicazione ha menu piuttosto complessi, pochi DataGridViews e PixtureBox , su cui sto disegnando alcune cose in 2D. Come ho detto, l'applicazione comunica molto con diversi dispositivi e con SQL server su entrambi i lati e, naturalmente, ha molti thread. Inoltre, ci sono molte finestre di dialogo varie. In questo momento nella versione di WinForms, è un casino di logica e UI mescolati insieme.

Puoi suggerirmi qualche approccio, come iniziare a separare la logica dall'interfaccia utente in un progetto così complesso?

Ho letto molte esercitazioni WPF / MVVM, ma ovviamente tutti gli esempi sono semplici e non riesco ancora a pensare in MVVM.

    
posta Majak 03.11.2015 - 16:52
fonte

1 risposta

0

È lo stesso approccio di qualsiasi altro importante refactoring.

  1. Test di unità incorporate per convalidare il comportamento del codice esistente.

  2. Identifica e isola piccole sezioni di codice che possono essere refactored.

  3. Refactor una sezione alla volta.

  4. Verificare che tutti i test delle unità (vedere il passaggio 1) continuino a passare. Se falliscono, correggi il tuo refactoring.

  5. Risciacqua e ripeti fino a quando non rimpiangi il giorno in cui hai deciso di ridefinire il codice base.

  6. Alla fine completerai il refactoring. Esci dal codice e promettiti di non ripetere mai più quegli errori.

Per quanto riguarda il modo in cui separare la logica aziendale dalla logica dell'interfaccia utente in MVVM. Per la maggior parte, tutta la tua logica di business dovrebbe vivere a livello di modello o inferiore. Tutta la logica relativa all'interfaccia utente, incluse le proprietà da associare, vivrà al livello View e ViewModel.

Una buona regola empirica su "È logica aziendale o logica dell'interfaccia utente" è la seguente. Se il comportamento del codice deve persistere indipendentemente dall'interfaccia utente, è la logica aziendale. Se il comportamento del codice è legato alla presentazione dei dati, questa è la logica dell'interfaccia utente.

    
risposta data 03.11.2015 - 17:29
fonte

Leggi altre domande sui tag