[.NETv4] Winforms vs WPF

[Verwijderd]

We hebben een applicatie dat bestaat uit een ActiveX control geschreven in C++ en een VB.NET GUI er om heen.
Deze applicatie (MapWindow GIS) is al bijna 10 jaar in ontwikkeling.
In de afgelopen jaren is de GUI door verschillende programmeurs aangepast en uitgebreid en is veel functionaliteit toegevoegd aan de ActiveX.

We zijn nu op het punt dat de VB.NET code niet meer onderhoudbaar is en we gaan de GUI herschrijven in C# voor .NETv4.

Nu is de eerste vraag gaan we verder met WinForms of stappen we over naar WPF.
Omdat dit een fundamentele keuze is, wil ik daar eerst meer over weten.

Ik heb al gezocht met Google en kwam vooral vergelijkingsartikelen van jaren terug tegen en daar kwam ook niet echt een duidelijke conclusie uit.

Mijn vragen zijn:
* Heeft iemand ervaring met zowel WPF en Winforms en wat zijn de voor- en nadelen?
* Maakt het nog wat uit dat we een ActiveX gebruiken?

Alvast bedankt.

[Woy]

Wat heb je zelf al gezocht en gevonden over de verschillen? Het is wel erg makkelijk om op deze manier een vraag neer te gooien, en niet ten minste het resultaat van je eigen onderzoek hier te plaatsen.

WPF is een compleet andere manier van GUI's ontwikkelen, ik vind het zelf erg fijn werken omdat je ( afhankelijk van de manier dat je werkt natuurlijk ) een veel duidelijker onderscheid hebt tussen je View en Logica.

Ik denk dat je eerst even je requirements op moet schrijven en kijken welke techniek daar het beste bij past.

[Coca-Cola]

Misschien ook wel handig om na te denken of je misschien ook ooit een web interface wilt hebben voor je applicatie.

[Verwijderd]

Ik heb inderdaad veel berichten gevonden van mensen die WPF gebruiken en er zeer tevreden over zijn.
Dat is ook de reden dat we overwegen de nieuwe GUI in WPF te maken.
Maar ik heb ook veel berichten gevonden dat men liever met WinForms blijven werken. De redenen zijn vaak niet geheel duidelijk.

We zitten nu nog in de onderzoeksfase en hebben nog niet veel van de nieuwe requirements op papier.
Misschien moet ik daar toch eerst mee beginnen

Een ActiveX control is een erg 'oude' techniek. Ik ben wel benieuwd of het überhaupt mogelijk is om een ocx met WPF te gebruiken. Ik kon daar nauwelijks iets over vinden.
Ikzelf heb geen ervaring met WPF, dat maakt het ook wat ingewikkelder

Zoals het nu lijkt gaan we geen webinterface maken voor onze applicatie. Voor wat wij mee bezig zijn (GIS) zijn al veel webinterfaces beschikbaar.

[BasieP]

Bij het herschrijven van een gui zou ik geen oude technieken willen gebruiken. Dus de vraag of je ActiveX wilt gebruiken gaat VOOR de vraag of je het kunt gebruiken.
Mijn suggestie zou zijn: niet doen! (tenzij je niet anders kunt, maar dat geloof ik niet)

Verder heeft WPF een voordeel omdat je makkelijk over kunt naar silverlight, maar wat wel direct een ding is, is dat je clients dan ook silverlight moeten hebben.

Verder vind ik WPF erg onhandig ontwikkelen, en raak ik door de xml files vaak de weg kwijt. In een windows forms applicatie kan je op alles 'go to definition' doen, en je weet waar je uitkomt.

Verder zijn er volgens mij geen dingen die je met WPF kan, maar niet met winforms. andersom zou ik niet zo durven zeggen, maar ik acht de kans wel groter.

Je zou nog punten aan winforms kunnen toewijzen omdat het zich bewezen heeft. WPF is niet redelijk nieuw (al bestaat het al een tijdje) en lang niet zo breed gebruikt als winforms.

Owja, en denk ook na over de expertise die je nodig hebt. Binnen een project wordt vaak vergeten dat je goede kennis moet hebben van je taal, tooling en omgeving. Dit is meer waard dan of die taal, tool of omgeving 'het beste' is.
Want zelfs als een van beide duidelijk beter is dan de ander, maar je hebt er niet de kennis van, kan ik maar 1 ding zeggen:
Don't touch that!

[Woy]

BasieP schreef op woensdag 10 augustus 2011 @ 12:45:
Bij het herschrijven van een gui zou ik geen oude technieken willen gebruiken. Dus de vraag of je ActiveX wilt gebruiken gaat VOOR de vraag of je het kunt gebruiken.
Mijn suggestie zou zijn: niet doen! (tenzij je niet anders kunt, maar dat geloof ik niet)

Dat zou je kunnen zeggen als je inderdaad een complete rewrite gaat doen. Maar meestal word een rewrite toch in stappen gedaan, en zul je dus soms oude componenten willen hergebruiken.

Ik denk dat het geen probleem moet zijn om die in WPF te integreren. Je kunt immers gewoon Winforms controls in WPF gebruiken dmv de WindowsFormsHost. Andersom is het volgens mij ook mogelijk om WPF controls in een winforms applicatie te hosten, dus je kunt ook een hybride applicatie maken.

[ Voor 39% gewijzigd door Woy op 10-08-2011 13:10 ]

[Verwijderd]

Woy schreef op woensdag 10 augustus 2011 @ 13:09:
[...]
dus je kunt ook een hybride applicatie maken.

Daar had ik nog niet aan gedacht. Dat zal een hoop mogelijke problemen kunnen oplossen.

Inderdaad gaan we de applicatie in delen herschreven. Eerst de GUI en de Business layer.
De ActiveX control zal waarschijnlijk altijd wel blijven omdat we veel berekeningen doen en dan is snelheid belangrijk.
Twee jaar terug is begonnen met een ActiveX-loze versie en die gaat niet goed overweg met grote databestanden (TIFF-bestanden >200MB) en is erg traag als het gaat om spatial operations zoals union, intersect, buffer, etc.

De eerdere opmerking over kennis is ook een goede.
Inderdaad hebben we wel iemand in het team nodig die wat van WPF af weet.

[Woy]

Verwijderd schreef op woensdag 10 augustus 2011 @ 13:36:
[...]
De ActiveX control zal waarschijnlijk altijd wel blijven omdat we veel berekeningen doen en dan is snelheid belangrijk.
Twee jaar terug is begonnen met een ActiveX-loze versie en die gaat niet goed overweg met grote databestanden (TIFF-bestanden >200MB) en is erg traag als het gaat om spatial operations zoals union, intersect, buffer, etc.

Want buiten een ActiveX kun je niet snel rekenen? Ik vind het eigenlijk nogal een gekke reden voor het gebruik van een ActiveX control.

[Verwijderd]

Uiteraard zijn er meer redenen om de ActiveX te behouden, maar dat is erg off-topic.

[roy-t]

Zelf heb ik jaren winforms gebruikt en ik gebruik nu pas een dikke maand WPF.

Ik kan je alleen maar zeggen dat ik ontzettend spijt heb dat ik niet eerder mezelf verdiept heb in WPF. (Nu moest het wel voor werk, dus ik had geen smoesjes).

De pros van WPF
-Compositie van controls is echt heel erg krachtig, je kunt alles overal kwijt (listbox in tooltip, etc...)
-Databinding maakt alles 10x makkelijker, maar alleen als je vanaf het begin er rekening mee houd, (tip gebruik, veel properties en gebruik de volgende snippet: propdp en druk daarna 2x op tab, dit scheel heel veel type werk als je verwacht dat een property gedatabind gaat worden).
-Code is beter gescheiden van view
-Rendered sneller
-Je kunt oude WinForms controls in WPF hosten, als dat echt moet (WindowsFormsHost)
Cons van WPFb
- Databinding er achteraf inhacken gaat moeizaam, het is echt iets wat je moet plannen voor de applicatie
- De meeste standaard controls zijn omdat ze zo aanpasbaar zijn wat kaal, je moet soms wel erg veel extra code/XAML schrijven om van een listview een echte datagrid te maken bijvoorbeeld, maar het kan wel en daarna werkt het erg goed en ziet het er erg mooi uit.

Pros WinForms
-Rijkere standaard controls
-Betere support vanuit de visuele editor in VS2008 (maar in Expression Blend en VS2010 geld dit mogelijk niet meer)
Cons WinForms
-Om eigen controls te maken en te stijlen moet je vaak 10x het wiel opnieuw uitvinden.
-Oud, traag, lelijk langzaam .


Ik zou dus echt voor WPF gaan, maar trek eerst een week of twee uit om het goed te leren kennen en plan dan pas je applicatie.


Overigens heeft WPF zich echt al bewezen, Visual Studio 2010 is bijvoorbeeld helemaal in WPF geschreven.

[ Voor 10% gewijzigd door roy-t op 10-08-2011 14:10 ]

[Guldan]

Ik onwikkel nu zelf een applicatie in silverlight ipv windows forms maar als ik een forms app zou moeten maken zou ik ook gebruik maken van WPF. Ik ben het voor de rest eens met Roy-t, maar als je wel veel databinding (dus met WPF) gaat doen dan is Resharper echt een uitkomst! Die ondersteunt een soort van intellisense voor XAML databinding. wanneer je dan een typfout gemaakt hebt dan zie je daar een blauw kringeltje onder en je krijgt gewoon intellisense op het object in de datacontext.

[ Voor 3% gewijzigd door Guldan op 10-08-2011 15:13 ]

[NickThissen]

roy-t schreef op woensdag 10 augustus 2011 @ 14:07:
Overigens heeft WPF zich echt al bewezen, Visual Studio 2010 is bijvoorbeeld helemaal in WPF geschreven.

Dat dacht ik eerst ook maar het blijkt toch niet zo te zijn. Veel dingen zijn nog steeds 'oud' en hebben ze niet naar WPF geconverteerd. Bijvoorbeeld de meeste tool windows (solution explorer, properties window etc) en de hele windows forms designer is nog geen WPF.
Zie hier.

[beany]

Ik ontwikkel al een paar jaar met WPF, en ik zou NOOIT meer een winforms app willen maken. Al staat er 1000 euro salaris verhoging tegen over!

De flexibiliteit, code en view scheiding(zoek op internet naar MVVM), de styling die relatief eenvoudig op controls toegepast kan worden, binding die enorm krachtig is, etc etc.

Het verdwalen in XAML's(xml files) herken ik niet. In tegendeel zelfs. Je hebt het ook een beetje zelf in de hand. Denk na wat je waar zet, dat voorkomt een hoop gedoe.

Als je zaken slim aanpakt kan je ook een hoop hergebruiken in andere applicaties(custom controls, styles, etc).

Maar als er nog geen enkele kennis van WPF in het bedrijf in huis is, ga shoppen. Kijk of je iemand kan inhuren(aannemen voor mijn part) en stuur wat ontwikkelaars op cursus. Dat scheelt enorm in leer tijd.

[Rhapsody]

roy-t schreef op woensdag 10 augustus 2011 @ 14:07:
Overigens heeft WPF zich echt al bewezen, Visual Studio 2010 is bijvoorbeeld helemaal in WPF geschreven.

Volgens mij is hoofdzakelijk de editor in WPF geschreven.

[Megamind]

beany schreef op woensdag 10 augustus 2011 @ 17:16:
...

Same here, we hebben pas een project succesvol afgrond wat volledig in WPF is geschreven icm een MSSQL database. Omdat het hier om een kiosk ging was het enorm handig dat de code en views zo goed gescheiden waren, je zat nooit te klooien in forms en van pagina's switchen gaat nu helemaal super.

We hebben hier ook een aantal oude OCX controls moeten gebruiken van de klant en deze kan je prima integreren.

Alle nieuwe niet web projecten worden hier direct in WPF gemaakt, en als je zelf goede controls schrijf kan je veel hergebruiken.

[-Rombo-]

Ik gebruik C# niet professioneel en heb dit ook volledig op mijn eigen zitten leren dus vanuit dat standpunt ben ik misschien niet zo een goede referentie.

Enkele jaren terug begonnen met C#/WinForms en sinds een maand of 4 bezig met C#/WPF.

Een gui er anders laten uitzien, eigen controls maken, ... is a peace of cake in WPF vergeleken met WinForms.
Bv: een button in een listbox steken samen met nog een foto erbij of eender wat gaat zeer simpel, zou eigenlijk niet direct weten hoe ik dit in WinForms moet doen.
De Bindings zijn ook zeer handig terwijl ik in WinForms daar eigenlijk niets van moest weten.

Maar WPF is veel moeilijker (te leren) dan WinForms (vind ik toch)

Als ge veel googled achter WPF komt ge ook dikwijls tegen 'steep learning curve' en dit zeker wel van toepassing maar zodra ge het wat gewoon begint te worden wilt ge niets meer in WinForms maken.

Ik ben dus volledig pro WPF!

[HawVer]

roy-t schreef op woensdag 10 augustus 2011 @ 14:07:

Cons WinForms
-Om eigen controls te maken en te stijlen moet je vaak 10x het wiel opnieuw uitvinden.
-Oud, traag, lelijk langzaam .

Zo niet waar. Traag, lelijk en langzaam heb je met de verkeerde controls gewerkt. Het voordeel dat WPF heeft tov Windows Forms i.c.m GDI is dat WPF beter gebruik maakt van de GPU voor zijn 2d renders. Als nadeel heeft WPF dat de objecten zwaarder zijn dan reguliere Windows forms objecten dus als het aantal toe neemt dat de performance afneemt. Overigens is GDI op hedendaagse systemen zo snel dat jij het verschil niet kan zien tussen WPF en GDI. Mijn ervaring is dat voor de basic gui dingen (dus geen animaties) WPF sneller is en dat als je data intensieve applicaties gebruikt die veel data op het scherm tonen, Windows forms nog wel eens een betere optie kan zijn.

Fatsoenlijke styling voor windows forms is inderdaad een tijdsintensief klusje.

-Rombo- schreef op woensdag 10 augustus 2011 @ 20:20:
Ik gebruik C# niet professioneel en heb dit ook volledig op mijn eigen zitten leren dus vanuit dat standpunt ben ik misschien niet zo een goede referentie.

Enkele jaren terug begonnen met C#/WinForms en sinds een maand of 4 bezig met C#/WPF.

Een gui er anders laten uitzien, eigen controls maken, ... is a peace of cake in WPF vergeleken met WinForms.
Bv: een button in een listbox steken samen met nog een foto erbij of eender wat gaat zeer simpel, zou eigenlijk niet direct weten hoe ik dit in WinForms moet doen.
De Bindings zijn ook zeer handig terwijl ik in WinForms daar eigenlijk niets van moest weten.

Maar WPF is veel moeilijker (te leren) dan WinForms (vind ik toch)

Als ge veel googled achter WPF komt ge ook dikwijls tegen 'steep learning curve' en dit zeker wel van toepassing maar zodra ge het wat gewoon begint te worden wilt ge niets meer in WinForms maken.

Ik ben dus volledig pro WPF!

toon volledige bericht

Ik denk dat voor WPF eigenlijk hetzelfde geldt als voor de Windows forms. Zolang je gebruik maakt van de basic interface objecten dat je behoorlijk uit de voeten kan. Maar zodra je wat dieper moet en echte eigen controls gaat schrijven dat het dan allemaal moeilijker wordt.

[ Voor 39% gewijzigd door HawVer op 10-08-2011 20:47 ]

[NickThissen]

HawVer schreef op woensdag 10 augustus 2011 @ 20:44:

[...]

Ik denk dat voor WPF eigenlijk hetzelfde geldt als voor de Windows forms. Zolang je gebruik maakt van de basic interface objecten dat je behoorlijk uit de voeten kan. Maar zodra je wat dieper moet en echte eigen controls gaat schrijven dat het dan allemaal moeilijker wordt.

Het sterke van WPF mbt standaard controls is juist dat je ze in WPF zo makkelijk kunt combineren. Een ListBox die als items bijvoorbeeld een button met een stukje tekst en een foto heeft schrijf je in WPF in een aantal seconden. In Winforms moet ik er niet aan denken zoiets te gaan maken. En toch zijn het allemaal standaard controls (listbox, button, label, etc), juist het feit dat je in WPF eigenlijk elke control in elke control kunt stoppen maakt dat je heel weinig naar custom controls hoeft te stappen, je kunt alles gewoon op je view zetten zoals je het wil. In Winforms moet je voor elke scheet een custom control gaan maken. Maak maar eens een TextBox met een plaatje aan de rechterkant, dat is toch een vrij standaard interface in veel gevallen (zoek velden etc). In WPF heb je dat zo voor elkaar door gewoon een image in een textbox te zetten. In Winforms kun je al meteen naar een custom control gaan en moet je volgens mij zelfs windows messages gaan onderscheppen om het plaatje fatsoenlijk te kunnen tekenen...

[beany]

HawVer schreef op woensdag 10 augustus 2011 @ 20:44:
[...]

Ik denk dat voor WPF eigenlijk hetzelfde geldt als voor de Windows forms. Zolang je gebruik maakt van de basic interface objecten dat je behoorlijk uit de voeten kan. Maar zodra je wat dieper moet en echte eigen controls gaat schrijven dat het dan allemaal moeilijker wordt.

De kracht van WPF is juist dat je makkelijk zelf controls kan maken, of van bestaande controls het uiterlijk compleet kan aanpassen.

WPF kan in het begin wat overweldigend zijn, maar zodra je het concept begrijpt wil je niks anders meer. ControlTemplates en Styles lijken wat vaag, terwijl het toch echt een goed doordacht concept is.

[roy-t]

HawVer schreef op woensdag 10 augustus 2011 @ 20:44:
[...]

Zo niet waar. Traag, lelijk en langzaam heb je met de verkeerde controls gewerkt. Het voordeel dat WPF heeft tov Windows Forms i.c.m GDI is dat WPF beter gebruik maakt van de GPU voor zijn 2d renders. Als nadeel heeft WPF dat de objecten zwaarder zijn dan reguliere Windows forms objecten dus als het aantal toe neemt dat de performance afneemt. Overigens is GDI op hedendaagse systemen zo snel dat jij het verschil niet kan zien tussen WPF en GDI. Mijn ervaring is dat voor de basic gui dingen (dus geen animaties) WPF sneller is en dat als je data intensieve applicaties gebruikt die veel data op het scherm tonen, Windows forms nog wel eens een betere optie kan zijn.

Fatsoenlijke styling voor windows forms is inderdaad een tijdsintensief klusje.

Dit is niet helemaal waar, juist door UI virtualization (wat makkelijk te implementeren is en wat al gebruikt wordt door oa listboxes) is ook het aantal controls dat actief en in geheugen staat sterk te limiteren. Verder is het zo dat waar ik nu werk ze wel het verschil tussen GDI en WPF merken qua performance, en dat dit een van de redenen is waarom ze over gaan op WPF. Vooral als er iets moet schuiven ben je flink de pinuut met WinForms, bij statische layouts valt het misschien wel mee, maar ik maak hier 'saaie' tools en zelfs daar wordt al een hoop geschoven, gedocked en gedaan.

(Sowieso is layouting in WPF echt geweldig, een paar keer "Auto" of "*" in de breedte of hoogte van een control en schuiven maar ).

[ Voor 5% gewijzigd door roy-t op 11-08-2011 11:22 ]

[beany]

Wat nog wel benadrukt mag worden(vind ik) is dat als je met WPF aan de slag gaat je echt een MVVM/MVC methodiek moet gaan gebruiken.

De vuist regel is, met MVVM, dat geen enkele code behind van een XAML code mag bevatten. Dat houd alles schoon en uiterst overzichtelijk. In ons project lukt dat met 99,8% van alle XAML's. Commands, bindings en custom controls dragen hier enorm aan bij, net als een 'motortje' om XAML's aan modellen te koppelen.

[Verwijderd]

Allemaal erg bedankt.
Ik heb meer response gekregen dat ik had gehoopt.

Ik begrijp nu dat we WPF serieus moeten gaan overwegen, uiteraard is het afhankelijk van de kennis in het team.
MVC wilde we sowieso gaan implementeren, dus dat is geen probleem

[beany]

Verwijderd schreef op donderdag 11 augustus 2011 @ 12:25:
Allemaal erg bedankt.
Ik heb meer response gekregen dat ik had gehoopt.

Ik begrijp nu dat we WPF serieus moeten gaan overwegen, uiteraard is het afhankelijk van de kennis in het team.
MVC wilde we sowieso gaan implementeren, dus dat is geen probleem

Kijk ook eens naar MVVM. WPF en MVVM is een erg gelukkig huwelijk

[R4gnax]

beany schreef op donderdag 11 augustus 2011 @ 12:37:
[...]

Kijk ook eens naar MVVM. WPF en MVVM is een erg gelukkig huwelijk

MVVM zoals Microsoft het voor WPF presenteert is eigenlijk gewoon een verkapte vorm van MVC.

Het Model in MVVM omvat value objects en proxies, net zoals je dat in het Model van MVC zou hebben. De View omvat enkel de presentatie logica, net als in MVC. Het ViewModel omvat de koppeling tussen het Model en de View en koppelt de view aan de rest van de applicatie. Grofweg dezelfde rol als een (View) Mediator in MVC. Tenslotte vormt de collectie van Commands in WPF samen het Controller gedeelte v/d MVC drie eenheid.

[beany]

R4gnax schreef op vrijdag 12 augustus 2011 @ 20:59:
[...]

MVVM zoals Microsoft het voor WPF presenteert is eigenlijk gewoon een verkapte vorm van MVC.

Het Model in MVVM omvat value objects en proxies, net zoals je dat in het Model van MVC zou hebben. De View omvat enkel de presentatie logica, net als in MVC. Het ViewModel omvat de koppeling tussen het Model en de View en koppelt de view aan de rest van de applicatie. Grofweg dezelfde rol als een (View) Mediator in MVC. Tenslotte vormt de collectie van Commands in WPF samen het Controller gedeelte v/d MVC drie eenheid.

Er zijn aanzienlijke verschillen tussen MVVM en MVC. Alleen al waar de input wordt afgevangen verschilt. Bij MVVM op de VIEW en bij MVC in de Controller. Ook de relaties(single of dual) tussen de onderlinge objecten verschillen tussen MVVM en MVC.