Procesarea ulterioară a unei aplicații UI mari - MFC cu pachetul de caracteristici 2008 sau C # și Winforms?

Nu oferiți prea multe detalii cu privire la ceea ce face codul vechi sau la structura acestuia. Dacă aveți anumite criterii de performanță, este posibil să doriți să mențineți o parte din codul dvs. în C ++. Veți avea mai ușor să faceți interop cu codul dvs. vechi, dacă acesta este expus în mod corect - puteți apela în codul de bază existent de la C# astăzi? Ar fi bine să te gândești la un proiect pentru a obține această structură corectă.

Pe punctul WPF, ai putea argumenta că WinForms poate fi mai adecvat. Mutarea la WinForms este un pas mare pentru tine și echipa ta. Poate că s-ar putea să fie mai confortabil cu mutarea la WinForms? Este mai bine documentat, mai multă experiență pe piață și util dacă aveți nevoie de sprijin pentru clienții Windows 2000.

You might be interested in Extending MFC Applications with the .NET Framework

Ceva ce trebuie luat în considerare este C ++/CLI , dar nu au experienta cu el.

Dacă te uiți la trecerea la C# și prin urmare, .NET, aș considera Windows Presentation Foundation mai degrabă decât WinForms. wpf este viitorul clienților inteligenți din .NET, iar abilitățile pe care le ridicați vor fi reutilizate dacă doriți să faceți aplicații Silverlight găzduite de browser.

Sunt de acord cu sentimentul WPF. Tag-ul/XML bazat pe UI pare să fie un pic mai portabil decât WinForms.

Cred că trebuie să vă gândiți și la echipa dvs., dacă nu există multe abilități curente C#, atunci acesta este un factor, însă evoluția pieței pentru dezvoltatorii MFC este în scădere și C# crește.

Poate că ar fi posibilă o abordare fragmentară? Am fost implicat în recodarea aplicațiilor vechi la C# destul de puțin și întotdeauna durează mult mai mult decât ați fi estimat, mai ales dacă păstrați un cod vechi sau echipa dvs. nu este cea care cunoaște C #.

Sunt dezvoltator pe o aplicație care are o tonă de cod MFC vechi și avem toate îngrijorările dvs. Un mare motor al strategiei noastre a fost eliminarea cât mai multor riscuri și incertitudini, ceea ce a însemnat evitarea Big Rescrierii. După cum știm cu toții, TBR eșuează de cele mai multe ori. Așadar, am ales o abordare incrementală care ne permite să păstrăm module care nu se schimbă în versiunea actuală, scriind noi caracteristici gestionate și furnizând caracteristici care primesc îmbunătățiri la gestionate.

Puteți face acest lucru în mai multe moduri:

1. Activați conținutul wpf pe vizualizările dvs. MFC (consultați aici )

2. Pentru aplicațiile MFC MDI, creați un nou cadru WinForms și găzduiți vizualizările MFC MDI (consultați aici )

3. Gestionați comenzile WinForms de la utilizatori în dialogurile și vizualizările MFC (consultați aici )

Problema cu adoptarea wpf (opțiunea 1) este că vă va cere să rescrieți toate UI-ul dvs. dintr-o dată, altfel va arăta destul de schizofrenic.

A doua abordare pare viabilă, dar foarte complicată.

A treia abordare este cea pe care am selectat-o ​​și a funcționat foarte bine. Vă permite să actualizați selectiv zonele din aplicația dvs., menținând în același timp coerența generală și fără a atinge lucruri care nu sunt rupte.

Pachetul de caracteristici Visual C ++ 2008 pare interesant, dar nu am jucat cu el. Se pare că s-ar putea ajuta cu problema dvs. de aspectul învechit. În cazul în care "panglica" ar fi prea jarring pentru utilizatorii dvs. s-ar putea uita la terțe părți MFC și/sau WinForms furnizori de control.

Recomandarea mea generală este că modificarea interop + incrementală este cu siguranță preferabilă schimbărilor de amploare.

După ce ați citit urmărirea dvs., pot confirma cu siguranță că câștigurile de productivitate ale cadrului depășesc cu mult investiția în învățarea acesteia. Nimeni din echipa noastră nu a folosit C# la începutul acestui efort și acum toți îl preferăm.

Vă mulțumesc tuturor cu amabilitate pentru răspunsurile dvs., este liniștitor să vezi că, în general, consensul urmează linia mea de gândire. Sunt în situația norocoasă că software-ul nostru rulează, de asemenea, pe propriul nostru hardware personalizat (pentru industria de radiodifuziune) - astfel încât alegerea sistemului de operare este de fapt a noastră și este împinsă pe clienții noștri. În prezent, executați XP/2000, dar văd o dorință de a vă deplasa rapid la Vista.

Cu toate acestea, trebuie să ne menținem controlul foarte fin asupra performanței GPU-ului, ceea ce presupune automat excluderea wpf și a accelerației hardware? Ar fi trebuit să fac acest lucru în postul meu original - îmi pare rău. Poate că este posibil să utilizați două unități de procesare grafică ... dar asta este o altă întrebare cu totul ...

Echipa nu are nici o experiență semnificativă în C# și nu sunt eu însăși expert, dar cred că beneficiile pe termen lung ale unui mediu gestionat depășesc probabil timpul necesar pentru a ajunge la viteză.

Se pare că Winforms și C# o au deocamdată.

În funcție de aplicație și de dorința clienților dvs. de a instala .NET (nu toate sunt), aș trece cu siguranță la WinForms sau WPF. Interopul cu codul C ++ este simplificat foarte mult prin refactorizarea codului non-UI în bibliotecile de clasă utilizând C ++/CLI (după cum ați observat în selecția de etichete).

Singura problemă cu wpf este că poate fi dificil să menținem aspectul și simțul actual. Mutarea la WinForms se poate face în timp ce se menține aspectul actual al GUI. wpf folosește un astfel de model diferit încât să încerce să păstreze aspectul actual ar fi probabil inutil și cu siguranță nu ar fi în spiritul WPF. De asemenea, wpf are performanțe slabe pe mașinile pre-Vista atunci când rulează mai multe procese WPF.

Sugestia mea este să aflu ce utilizează clienții tăi. Dacă majoritatea s-au mutat la Vista și echipa dvs. este pregătită să pună o mulțime de lucruri GUI, aș spune să sărind WinForms și să mă mut în WPF. Altfel, arata cu siguranta serios la WinForms. În ambele cazuri, o bibliotecă de clase în C ++/CLI este răspunsul la preocupările dvs. interop.