Attualmente sto lavorando su un'applicazione MDI MFC legacy molto grande. Ha un gran numero di elementi dell'interfaccia utente: barre degli strumenti ancorabili, controlli personalizzati, menu contestuali, ecc. È un'applicazione di elaborazione delle immagini in modo che le viste principali vengano visualizzate utilizzando DirectX e OpenGL. Il prodotto ha circa 10 anni e una delle priorità qui è di aggiornarne l'aspetto grafico.Quali sono alcune tecniche per la migrazione di un'applicazione MFC di grandi dimensioni in WPF/.NET?
Sapendo che Microsoft ha svolto un buon lavoro di fornitura dell'interoperabilità tra C++/MFC e .NET ho pensato che avrebbe senso migrare il codice base in modo incrementale. Quello con cui sto combattendo ora è da dove cominciare.
Un approccio è quello di estrarre il framework MFC con WPF e riutilizzare il più possibile il codice C++. Questo ci consentirà di massimizzare i benefici dell'architettura WPF, ma significherà un lungo periodo di sviluppo finché non saremo completamente funzionanti.
Un altro approccio consiste nel sostituire i controlli MFC uno alla volta con le controparti WPF. Questo ci permetterà di lavorare in modo incrementale. La mia preoccupazione per questo approccio è che significa che ci sarà un sacco di punti di connessione tra il codice gestito e non gestito e non sono sicuro da dove iniziare con la sostituzione di cose come il menu principale e le barre degli strumenti.
Oppure c'è un'altra opzione qui che non vedo?
Qualsiasi suggerimento o collegamento a informazioni su questo argomento sarebbe apprezzato.
Aggiornamento: DavidK ha sollevato alcune domande eccellenti, quindi aggiungo le motivazioni alla base.
1) lo sviluppo futuro del prodotto
questo prodotto è ancora attivamente sviluppato con nuove caratteristiche sempre aggiunti su base regolare. Ho pensato che avrebbe molto senso provare a migrare lentamente verso C#/WPF. Nella mia limitata esperienza con C#/WPF ho riscontrato che i guadagni di produttività sono sorprendenti rispetto al lavoro in C++/MFC.
L'altra grande cosa che stiamo ottenendo con WPF è la possibilità di sfruttare i sistemi multi-testa. Le applicazioni MFC sono limitate a un singolo frame di primo livello, rendendo molto difficile sfruttare più monitor.
2) la ritenzione dei dipendenti e il reclutamento
Sta diventando sempre più difficile da trovare gli sviluppatori che sono disposti a lavorare su MFC. È anche importante per lo sviluppo della carriera degli attuali sviluppatori ottenere visibilità sulle nuove tecnologie.
Darei più di un voto, se potessi. –
la migrazione ideale da MFC è di andare con QT; Almeno allora i tuoi attuali sviluppatori non staranno chiedendo a gran voce di sviluppare usando la nuova tecnologia GUI che uscirà tra qualche anno :) – gbjbaanb
Il problema con QT è che si tratta di un passaggio laterale da MFC piuttosto che di un balzo in avanti in termini di tecnologia e guadagni di produttività. Non vedo alcun motivo valido per passare da MFC a QT a meno che non si stia cercando una soluzione multipiattaforma. Per un negozio Windows, quella mossa non avrebbe alcun senso. –