2010-08-11 7 views
13

Esiste un pratico modo per noi di evolvere lentamente un'applicazione WinForms a WPF senza creare un incubo supporto per noi stessi con gli scenari di interoperabilità strani?WinForms to WPF - Come ci arriviamo da qui?

informazioni Background:

Abbiamo una grande applicazione WinForms corazzata grigio che è fortemente utilizzato da un gruppo interno di circa 60-75 utenti. Stiamo iniziando a imbattersi in luoghi dove potremmo vedere alcuni benefici dall'avere l'app in WPF, ma non è sufficiente per giustificare un grande progetto di riscriverlo completamente. Tutte le schermate dell'app sono controlli utente WinForms autonomi e l'app WinForms è solo una shell che gestisce i menu, i moduli di apertura/chiusura, fornisce alcuni metodi di supporto condivisi, ecc ...

Finora, il migliore l'idea che abbiamo avuto è quella di convertire l'applicazione shell in WPF e quindi ospitare i controlli utente WinForms al suo interno. Abbiamo pensato che avremmo potuto convertire i controlli utente nel tempo, legando tali modifiche alle iniziative che hanno un valore commerciale sufficiente a supportare il lavoro aggiuntivo. Sono preoccupato per quanto bene funziona l'interoperabilità e come influirà sulle prestazioni. Sono anche preoccupato di come passiamo a un nuovo look per l'app. Sembrerebbe strano rendere l'app shell sgargiante e quindi avere vecchi controlli utente in grigio corazzato ospitati al suo interno e sembra anche strano creare l'app shell in WPF e farla apparire come in WinForms.

Se uno dei Caliburn, Prism, o in un altro quadro simile avrebbe facilitare la transizione, saremmo aperti a esplorare quelle opzioni pure.

risposta

11

Eravamo in una situazione simile e abbiamo scelto il seguente percorso: All'inizio abbiamo iniziato a ospitare alcune finestre WPF nel guscio applicazione (ancora WinForms). Naturalmente c'era una differenza visibile ma abbiamo ridotto la differenza deliberatamente abbassando le finestre. Abbiamo pensato che prima di convertire le finestre/i controlli rimanenti sarebbe stato più facile "aggiornare" a un'esperienza più vivida in quanto l'interfaccia utente sarebbe interamente WPF e potremmo coinvolgere un designer grafico per lavorare la loro magia basata su XAML.

Ora abbiamo raggiunto il punto in cui la maggior parte delle finestre sono WPF. Abbiamo avviato il processo di conversione dell'app shell WinForms in un'applicazione shell basata su WPF che ospita i restanti WinForm. Abbiamo una sorta di colori noiosi, ma gli utenti hanno iniziato a notare la differenza e, anche se è piccolo, i nostri utenti apprezzano ancora il cambiamento positivo incrementale. Non troppo lungo e ci ritireremo l'ultimo WinForm. Sarà questo il punto in cui lasceremo i nostri grafici fuori dal guinzaglio!

Per quanto riguarda le prestazioni: posso certamente non fare una dichiarazione generale, in quanto pesantemente dipende dalle vostre particolari controlli/finestre. Nel nostro prodotto (alcune centinaia di finestre) non abbiamo riscontrato alcun problema di prestazioni significativo correlato al mix di WPF e WinForms.

Non ci siamo guardati in uno dei quadri, così ho paura che non posso commentare su quelli.

+1

+1 Questo descrive le mie esperienze molto bene. Inoltre, ecco una interessante sessione PDC su come è stato implementato Visual Studio 2010 utilizzando l'interoperabilità di NET Framework 4: http://microsoftpdc.com/2009/CL09 –

+1

Non sono sicuro che ci sia una risposta "giusta" a questo, ma io penso che questo sia l'approccio che probabilmente finiremo per prendere. –

+0

e in tutto questo sforzo, pagato dal business, hai fornito nuove funzionalità utili agli utenti finali, o ti sei divertito a fare gli occhi? – smirkingman

4

Grande domanda, attualmente la maggior parte del lavoro in WPF riguarda la conversione della vecchia applicazione WinForms in WPF. Dalla mia esperienza, il caso migliore è quello di creare l'applicazione da zero in base a vecchi requisiti/applicazioni. Fortunatamente ho fatto parte di un progetto in cui abbiamo riscritto l'applicazione da zero e sono sicuro che ci sono voluti meno tempo/investimenti e quindi unire i due.

Personalmente ritengo che avrebbe creato un casino se avessimo provato a mescolare i due. Un altro punto è che sarà difficile progettare l'applicazione mista in modo efficiente.

Nel mio progetto attuale (che è un grande progetto che va dagli ultimi 10 anni) stiamo convertendo il modulo applicativo per modulo base. Fortunatamente per noi la nostra applicazione è composta da varie applicazioni più piccole, quindi convertirle una per una è più facile. Nel tuo caso direi che si identificano le aree che possono essere totalmente convertiti in WPF e iniziare a costruirli in WPF, come suggerito qui -

Windows Forms - WPF Interoperabilità FAQ: http://windowsclient.net/learn/integration.aspx

Vorrei anche suggerire utilizzare alcuni strumenti per convertire i moduli Windows in XAML (WPF); che sicuramente ti aiuterà a risparmiare un po 'di tempo.

su Windows Form al convertitore di WPF: http://wf2wpf.codeplex.com/

su Windows Form a XAML Converter: http://www.ingeniumsoft.com/Products/WinForm2XAML/tabid/63/language/en-US/Default.aspx

su Windows Form al convertitore di Windows Presentation Foundation : http://www.spiderwan.com/spiderwan/ConvertWinFormToWPF/WinFormToWPF.aspx

+1

Generalmente preferisco l'approccio di conversione incrementale descritto da John, ma sono d'accordo che ci sono momenti in cui ha senso riscrivere i requisiti originali. Tuttavia, non sono affatto d'accordo sul fatto che Paul G guardi gli strumenti di conversione da Windows Form a WPF: chi utilizza tali strumenti finisce invariabilmente con un'applicazione che è ancora più difficile da gestire rispetto all'app Winforms. Se fatte correttamente, le applicazioni WPF sono molto più semplici e facili da gestire rispetto alle Winform equivalenti. Il tempo dedicato alla creazione di modelli di visualizzazione di qualità e XAML ripagherà se stesso dieci volte, soprattutto quando si esegue una riscrittura. –

+0

Punto preso, la progettazione di modelli di vista e XAML te stesso sarà sempre meglio. Volevo solo far sapere a Paul delle opzioni disponibili (per risparmiare tempo ovviamente). – akjoshi

Problemi correlati