A prova di futuro un'applicazione dell'interfaccia utente di grandi dimensioni: MFC con Feature Pack 2008 o C# e Winforms?

Question

La mia azienda ha sviluppato un prodotto di lunga data utilizzando MFC in Visual C++ come standard de facto per lo sviluppo dell'interfaccia utente.La nostra codebase contiene MOLTO codice legacy/arcaico che deve essere mantenuto operativo.Parte di questo codice è più vecchio di me (scritto originariamente alla fine degli anni '70) e alcuni membri del nostro team utilizzano ancora Visual Studio 6.

Fortunatamente, però, internamente siamo giunti alla conclusione che il nostro prodotto sembra un po' antiquato rispetto a quello dei nostri concorrenti e che bisogna fare qualcosa.

Attualmente sto lavorando su una nuova area dell'interfaccia utente che è abbastanza separata dal resto del prodotto.Mi è stata quindi data la possibilità di provare "nuovi" stack tecnologici come una sorta di banco di prova prima che inizi il lungo processo di spostamento sul resto dell'interfaccia utente.

Utilizzo C# con Windows Forms e .net Framework da un po' nel mio tempo libero e mi diverto, ma sono un po' preoccupato per i mal di testa causati dall'interoperabilità.Anche se questo particolare ramo dell'interfaccia utente non richiederà molta interoperabilità con la base di codice C++ legacy, posso prevedere che questo diventerà un problema in futuro.

L'alternativa è semplicemente continuare con MFC, ma provare a sfruttare il nuovo pacchetto di funzionalità fornito con VS2008.Immagino che questa sia l'opzione più semplice, ma mi preoccupo della longevità e di non sfruttare la bontà di .net...

Quindi, quale scelgo?Siamo un piccolo team quindi la mia raccomandazione sarà molto probabilmente accettata come direzione futura per il nostro sviluppo: voglio farlo bene.

MFC è morto?C#/Winforms è la strada da seguire?C'è qualcos'altro che mi sfugge totalmente?Aiuto molto apprezzato!

Answer 1

Sono uno sviluppatore di un'app che contiene moltissimi codici MFC legacy e abbiamo tutti le tue stesse preoccupazioni.Un fattore determinante per la nostra strategia è stato quello di eliminare quanto più rischio e incertezza possibile, il che significava evitare la Grande Riscrittura.Come tutti sappiamo, la TBR fallisce la maggior parte delle volte.Quindi abbiamo scelto un approccio incrementale che ci consente di preservare i moduli che non verranno modificati nella versione corrente, scrivendo nuove funzionalità gestite e portando funzionalità che ottengono miglioramenti nella versione gestita.

Puoi farlo in diversi modi:

1. Ospita il contenuto WPF sulle tue visualizzazioni MFC (vedi Qui)

2. Per le app MFC MDI, crea un nuovo framework WinForms e ospita le tue visualizzazioni MFC MDI (vedi Qui)

3. Ospitare i controlli utente WinForms nelle finestre di dialogo e nelle visualizzazioni MFC (vedere Qui)

Il problema con l'adozione di WPF (opzione 1) è che richiederà di riscrivere tutta l'interfaccia utente in una volta, altrimenti sembrerà piuttosto schizofrenico.

Il secondo approccio sembra praticabile ma molto complicato.

Il terzo approccio è quello che abbiamo selezionato e ha funzionato molto bene.Ti consente di aggiornare selettivamente le aree della tua app mantenendo la coerenza generale e senza toccare le cose che non sono rotte.

Il Feature Pack di Visual C++ 2008 sembra interessante, anche se non ci ho giocato.Sembra che potrebbe aiutare con il tuo problema di aspetto obsoleto.Se il "nastro" fosse troppo fastidioso per i tuoi utenti, potresti guardare i fornitori di controlli MFC e/o WinForms di terze parti.

La mia raccomandazione generale è che l'interoperabilità + la modifica incrementale siano decisamente preferibili alle modifiche radicali.

---

Dopo aver letto il tuo follow-up, posso sicuramente confermare che i guadagni di produttività del framework superano di gran lunga l'investimento nell'apprenderlo.Nessuno nel nostro team aveva utilizzato C# all'inizio di questo progetto e ora lo preferiamo tutti.

Answer 2

A seconda dell'applicazione e della volontà dei tuoi clienti di installare .NET (non tutti lo sono), passerei sicuramente a WinForms o WPF.L'interoperabilità con il codice C++ è estremamente semplificata eseguendo il refactoring del codice non UI nelle librerie di classi utilizzando C++/CLI (come hai notato nella selezione dei tag).

L'unico problema con WPF è che potrebbe essere difficile mantenere l'aspetto attuale.Il passaggio a WinForms può essere effettuato mantenendo l'aspetto attuale della GUI.WPF utilizza un modello così diverso che tentare di mantenere il layout attuale sarebbe probabilmente inutile e sicuramente non sarebbe nello spirito di WPF.Apparentemente WPF ha anche prestazioni scarse sulle macchine pre-Vista quando è in esecuzione più di un processo WPF.

Il mio suggerimento è di scoprire cosa utilizzano i tuoi clienti.Se la maggior parte si è spostata su Vista e il tuo team è pronto a svolgere molto lavoro sulla GUI, direi di saltare WinForms e passare a WPF.Altrimenti, guarda seriamente WinForms.In entrambi i casi, una libreria di classi in C++/CLI è la risposta ai tuoi problemi di interoperabilità.

Answer 3

Non fornisci molti dettagli su cosa fa il tuo codice legacy o su come è strutturato.Se hai determinati criteri di prestazione, potresti voler mantenere parte della tua base di codice in C++.Ti sarà più facile eseguire l'interoperabilità con il tuo vecchio codice se è esposto nel modo giusto: puoi richiamare la base di codice esistente da C# oggi?Potrebbe valere la pena pensare a un progetto per ottenere questa struttura corretta.

Per quanto riguarda WPF, si potrebbe sostenere che WinForms potrebbe essere più appropriato.Il passaggio a WinForms è un grande passo per te e il tuo team.Forse potrebbero sentirsi più a loro agio con il passaggio a WinForms?È meglio documentato, ha più esperienza nel mercato ed è utile se è ancora necessario supportare i client Windows 2000.

Potrebbe interessarti Estensione delle applicazioni MFC con .NET Framework

Qualcos'altro da considerare è C++/CLI, ma non ho esperienza in merito.

Answer 4

Grazie a tutti per le vostre risposte, è rassicurante vedere che generalmente il consenso segue la mia linea di pensiero.Mi trovo nella fortunata situazione che il nostro software funziona anche sul nostro hardware personalizzato (per il settore broadcast), quindi la scelta del sistema operativo è davvero nostra e spetta ai nostri clienti.Attualmente utilizziamo XP/2000, ma vedo il desiderio di passare presto a Vista.

Tuttavia, dobbiamo anche mantenere un controllo molto preciso sulle prestazioni della GPU, il che immagino escluda automaticamente WPF e l'accelerazione hardware?Avrei dovuto sottolineare questo punto nel mio post originale: scusate.Forse è possibile utilizzare due GPU...ma questa è tutta un'altra questione...

Il team non ha alcuna esperienza significativa in C# e io stesso non sono un esperto, ma penso che i vantaggi complessivi a lungo termine di un ambiente gestito probabilmente superino il tempo necessario per mettersi al passo.

Sembra che Winforms e C# ce l'abbiano per ora.

Answer 5

Se dovessi considerare il passaggio a C# e quindi a .NET, prenderei in considerazione Windows Presentation Foundation anziché WinForms.WPF è il futuro dei client intelligenti in .NET e le competenze acquisite potrai riutilizzare se desideri creare applicazioni Silverlight ospitate su browser.

Answer 6

Sono d'accordo con il sentimento del WPF.L'interfaccia utente basata su tag/XML sembrerebbe un po' più portabile di WinForms.

Immagino che anche tu debba considerare il tuo team, se non ci sono molte competenze attuali in C#, allora questo è un fattore, ma in futuro il mercato degli sviluppatori MFC sta diminuendo e C# sta crescendo.

Forse sarebbe possibile una sorta di approccio frammentario?Sono stato coinvolto per un bel po' nella ricodifica delle applicazioni legacy in C# e ci vuole sempre molto più tempo di quanto si potrebbe stimare, soprattutto se si mantiene del codice legacy o se il proprio team non ha molta dimestichezza con C#.