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

Compania mea a dezvoltat un produs de lungă durată folosind MFC în Visual C ++ ca standard defacto pentru dezvoltarea UI. Baza noastră de coduri conține NUMĂRUL codului vechi/arhaic care trebuie păstrat operațional. Unele din acest cod sunt mai vechi decât mine (inițial scrise la sfârșitul anilor 70) și unii membri ai echipei noastre sunt încă pe Visual Studio 6.

Cu toate acestea, sa ajuns la o concluzie internă că produsul nostru pare a fi oarecum vechi față de concurenții noștri și că trebuie făcut ceva.

În prezent, lucrez la o nouă zonă a UI, care este destul de separată de restul produsului. Prin urmare, mi sa oferit șansa de a încerca stive noi de tehnologie ca un fel de probă înainte de începerea lungului proces de deplasare în restul UI.

Am folosit C# cu Windows Forms și framework-ul .net pentru o vreme în timpul liber și mă bucur, dar sunt oarecum îngrijorat de durerile de cap cauzate de interop. În timp ce această ramură particulară a UI nu va necesita mult interop cu codul bazat pe C ++ moștenit, văd că acest lucru devine o problemă în viitor.

Alternativa este doar să continue cu MFC, dar încercați să profitați de noul pachet de caracteristici livrat cu VS2008. Aceasta este cea mai ușoară opțiune, dar mă îngrijorez de longevitate și nu profit de bunătatea care este .net ...

Deci, pe care o aleg? Suntem o echipă mică, așa că recomandarea mea va fi probabil acceptată ca o direcție viitoare pentru dezvoltarea noastră - vreau să am dreptate.

MFC este mort? Este C #/Winforms calea de urmat? Mai lipsesc altceva? Ajutor foarte apreciat!

0
fr hi bn
Da, MFC este mort. WinForms moare. În acest moment, calea de urmat este WPF. Trecerea de la MFC la WinForms va reduce costurile substanțial, dar trecerea de la WinForms la wpf va reduce costurile dramatic. WinForms este o opțiune bună pentru persoanele care încă mai au nevoie de suport pentru Windows 2000 sau Windows Mobile. DirectX este încă cea mai bună pentru jocuri 3D și CAD. IMHO, toți ceilalți ar trebui să ignore în întregime WinForms și să se mute direct la WPF.
adăugat autor Ray Burns, sursa

6 răspunsuri

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.

0
adăugat

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.

0
adăugat

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 #.

0
adăugat

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.

0
adăugat
Efortul/renunțarea la acest lucru este sumbră. Să nu mai vorbim că nu veți niciodată căutați pixel-cu-pixel dreapta. Veți ajunge cu un efect de "vale ciudat".
adăugat autor Aidan Ryan, sursa
Aveți posibilitatea ca tema dvs. wpf să arate ca și vechile controale de stil.
adăugat autor Andy Dent, sursa
Obținerea de stiluri wpf pixel-perfect ar putea dura mult timp DAR, în câteva ore, am reușit să obțin stilurile unei aplicații atât de precise încât nimeni - și nici măcar pe cei din sistemul de asigurare a calității - nu a realizat că noile secțiuni erau ușor diferite.
adăugat autor Ray Burns, sursa

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ă.

0
adăugat
GPU-ul pare, de asemenea, să aibă o influență uriașă asupra utilizării memoriei WPF.
adăugat autor Aidan Ryan, sursa
Vă mulțumim pentru info Ray Burns. Hrana pentru minte.
adăugat autor Ali Parr, sursa
Nu știu dacă acest lucru afectează situația dvs. sau nu, dar există cel puțin o situație în care GPU-ul nu este deloc utilizat atunci când rulează WPF: Remote Desktop (RDP/Terminal Services). Mai precis, GPU-ul mașinii de la distanță nu este deloc utilizat atunci când rulează aplicații wpf acolo. Sub RDP 6.0 primitivele sunt transferate înapoi la client pentru redare.
adăugat autor Ray Burns, sursa

Î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.

0
adăugat
Furnizați referințe pentru performanța slabă a wpf cu mai multe instanțe - aceasta ar putea fi o problemă cheie pentru noi!
adăugat autor Andy Dent, sursa
Una dintre mașinile mele de dezvoltare este un dual-monitor Windows XP și am frecvent câteva aplicații wpf vizibile pe ecran. Nu am observat niciun fel de probleme legate de performanță. Desigur, niciuna dintre aplicațiile pe care le folosesc pentru dezvoltare nu este o aplicație grafică reală cu o mulțime de obiecte în mișcare. Dacă s-ar întâmpla acest lucru, problema partajării GPU ar putea deveni vizibilă.
adăugat autor Ray Burns, sursa
Modelul driverului de afișare pentru Windows Vista ( msdn.microsoft.com/en-us/library/ aa480220.aspx ), de la MSDN
adăugat autor Zooba, sursa