Welke dotnet GUI technologie best future proof: Winform/WPF

[GabberKooij]

Momenteel zijn we aan het belissen of we WPF danwel Winforms gaan gebruiken.
we vragen ons daarbij af welke technologie het langst ondersteund zal worden door Microsoft, kan iemand me daar meer over vertellen?
Zijn er al B2B applicaties die WPF gebruiken? Of wordt dan meestal Winforms gebruikt?

Daarnaast zijn nog een paar overwegingen die een rol spelen:

• WPF ondersteuning in vista en Windows 7 schijnt goed te zijn, in Xp is de tekst minder duidelijk.
• Winforms ziet er anders uit onder XP dan onder Vista/7?
• We willen de GUI zowel vanuit een desktop applicatie als vanuit een Autocad plugin gebruiken.

Nog andere valkuilen die we in onze overweging mee moeten nemen?

[beany]

WPF is here to stay! Zelfs Visual Studio is met WPF gemaakt! Ik denk dat je je dus geen zorgen hoeft te maken dat het snel weer verdwijnt

Onder XP is WPF prima, ik zie niet echt verschil onder Win7. Er zijn in .Net 3.51 wel wat text scherpte problemen, maar die zijn in .Net 4 opgelost(.Net 4 en VS2010 komen ergens deze maand of in april, als het goed is)

Of WPF vanuit een Autocad plugin te gebruiken is weet ik niet, geen ervaring in.

Ik zit momenteel bij een bedrijf wat zwaar inzet op WPF. De complete applicatie line-up gaat over naar WPF, en het zijn geen kleine applicaties!

Ik persoonlijk denk, even Autocad daargelaten, dat WPF de beste keuze zal zijn. Je kan in WPF bijna alle GUI's maken die je wil. In WinForms gaat dat wat lastiger, je zit erg vast aan de standaard controls. Als het moet kan je in WPF een WinForms look maken(die soort van standaard is in WPF).

Kleine tip, als je met WPF aan de slag gaat: ga eens kijken naar MVVM (Model View ViewModel). http://blogs.msdn.com/dph...he-viewmodel-pattern.aspx en een plaatje zegt meer dan 1000000 woorden, dit is het beste overzichtsplaatje van MVVM wat ik ooit heb gezien: http://karlshifflett.file.../11/wpflobmvvm-thumb1.png

[ Voor 11% gewijzigd door beany op 11-03-2010 08:36 ]

[EfBe]

beany schreef op donderdag 11 maart 2010 @ 08:31:
WPF is here to stay! Zelfs Visual Studio is met WPF gemaakt! Ik denk dat je je dus geen zorgen hoeft te maken dat het snel weer verdwijnt

VS.NET 2010 is voor een groot deel in WPF gemaakt, maar de rest niet. Ook heeft men veel moeten backporten naar 3.5 (via service pack, komt nog) om text uberhaupt leesbaar te krijgen.

Ik zit momenteel bij een bedrijf wat zwaar inzet op WPF. De complete applicatie line-up gaat over naar WPF, en het zijn geen kleine applicaties!

Voor line-of-business applications is er geen reden om voor WPF te kiezen boven winforms, tenzij men geen kennis heeft van winforms en dus toch een UI framework moet leren. Als je al winforms kennis hebt is het onzinnig om applicaties om te zetten naar WPF want je wint er niets mee (behalve dan dat je IDE vaak crasht, tot .net 4.0 gereleased wordt je text onscherp is en door de bank genomen je met minder 3rd party controls toe moet)

Ik persoonlijk denk, even Autocad daargelaten, dat WPF de beste keuze zal zijn. Je kan in WPF bijna alle GUI's maken die je wil. In WinForms gaat dat wat lastiger, je zit erg vast aan de standaard controls. Als het moet kan je in WPF een WinForms look maken(die soort van standaard is in WPF).

In winforms kun je ook iedere UI maken die je wilt, en veelal gemakkelijker, want er zijn inmens veel 3rd party (gratis en commercieel) controls beschikbaar als ook een inmense hoeveelheid articles online hoe iets te bereiken. Voor WPF is dat niet het geval.

Kleine tip, als je met WPF aan de slag gaat: ga eens kijken naar MVVM (Model View ViewModel). http://blogs.msdn.com/dph...he-viewmodel-pattern.aspx en een plaatje zegt meer dan 1000000 woorden, dit is het beste overzichtsplaatje van MVVM wat ik ooit heb gezien: http://karlshifflett.file.../11/wpflobmvvm-thumb1.png

Of je maakt gewoon wat user controls in winforms en bent sneller klaar. MVVM en aanverwante patterns creeeren veel overhead (extra code) waar de noodzaak niet echt duidelijk van is (immers, je kunt prima UIs maken zonder al die extra code).

[beany]

EfBe schreef op donderdag 11 maart 2010 @ 09:18:
[...]

VS.NET 2010 is voor een groot deel in WPF gemaakt, maar de rest niet. Ook heeft men veel moeten backporten naar 3.5 (via service pack, komt nog) om text uberhaupt leesbaar te krijgen.

Text is leesbaar, in sommige rare gevallen is de text niet scherp(wel leesbaar). Dit is dus opgelost in .Net 4

[...]

Voor line-of-business applications is er geen reden om voor WPF te kiezen boven winforms, tenzij men geen kennis heeft van winforms en dus toch een UI framework moet leren. Als je al winforms kennis hebt is het onzinnig om applicaties om te zetten naar WPF want je wint er niets mee (behalve dan dat je IDE vaak crasht, tot .net 4.0 gereleased wordt je text onscherp is en door de bank genomen je met minder 3rd party controls toe moet)

IDE crashed niet vaak(gebeurt niet vaker dan bij niet WPF projecten). Waarschijnlijk is jouw WPF ervaring al wat oud, want er is inderdaad een periode geweest dat de IDE regelmatig onderuit ging. Dit is tegenwoordig dus niet meer zo.

Tevens is het zo dat je heel makkelijk in WPF zelf controls kan maken en VEEL meer controle hebt over de layout van controls en hun posities. Dit is in WinForms niet zo, daar is alles veel beperkter. Afwijkende UI's zijn makkelijker te maken.

[...]

In winforms kun je ook iedere UI maken die je wilt, en veelal gemakkelijker, want er zijn inmens veel 3rd party (gratis en commercieel) controls beschikbaar als ook een inmense hoeveelheid articles online hoe iets te bereiken. Voor WPF is dat niet het geval.

Klopt, er zijn totaal geen artikelen over WPF.

Ik denk dat je in WPF sneller een andere look kan creeeren dan in WinForms. Of alleen al het tonen van data in een list, waarbij de data anders is opgemaakt dan de standaard die er is in WinForms.

[...]

Of je maakt gewoon wat user controls in winforms en bent sneller klaar. MVVM en aanverwante patterns creeeren veel overhead (extra code) waar de noodzaak niet echt duidelijk van is (immers, je kunt prima UIs maken zonder al die extra code).

Ehhh, verdiep je eens in MVVM ?? Het MVVM pattern helpt je businesslogica/domain models te scheiden van je UI. Iets wat je toch wel wilt lijkt mij??

[Rhapsody]

Hier staat een mooie uitleg; http://windowsclient.net/...rs/when-to-adopt-wpf.aspx

[EfBe]

beany schreef op donderdag 11 maart 2010 @ 09:58:
[...]
Text is leesbaar, in sommige rare gevallen is de text niet scherp(wel leesbaar). Dit is dus opgelost in .Net 4

die 'rare' gevallen zijn niet zo 'rare' maar vrij vaak voorkomend. In .NET 4 is het opgelost, maar dat is nog niet uit, en duurt ook nog wel even voordat het op ieders PC staat.

[...]
IDE crashed niet vaak(gebeurt niet vaker dan bij niet WPF projecten). Waarschijnlijk is jouw WPF ervaring al wat oud, want er is inderdaad een periode geweest dat de IDE regelmatig onderuit ging. Dit is tegenwoordig dus niet meer zo.

2008? Mja, ik weet niet wie je voor de gek wilt houden, maar WPF designers crashen nog steeds, wel minder vaak na Sp1 voor 2008, maar nog steeds. Met winforms heb ik nooit een crash.

Tevens is het zo dat je heel makkelijk in WPF zelf controls kan maken en VEEL meer controle hebt over de layout van controls en hun posities. Dit is in WinForms niet zo, daar is alles veel beperkter. Afwijkende UI's zijn makkelijker te maken.

Ik zei ook 'line of business applications'. Geen mediaplayer, maar applicaties met grids, input velden etc. het 'saaie' werk.

[...]
Klopt, er zijn totaal geen artikelen over WPF.

Ik denk dat je in WPF sneller een andere look kan creeeren dan in WinForms. Of alleen al het tonen van data in een list, waarbij de data anders is opgemaakt dan de standaard die er is in WinForms.

Dat je scaling niet noemt...

Het lijstvoorbeeld is wel een aardige, maar dat is te counteren met grids en het grote scala beschikbare controls en voorbeelden. Ook is het nog maar afwachten wat MS gaat doen met WPF, aangezien Silverlight zo langzamerhand net zoveel begint te kunnen.

[...]
Ehhh, verdiep je eens in MVVM ?? Het MVVM pattern helpt je businesslogica/domain models te scheiden van je UI. Iets wat je toch wel wilt lijkt mij??

Waarom zou dat normaliter niet kunnen, dan? Jij moet een apart view-model maken, zonder enige reden, anders dan 'stel je voor dat'. Agile schrijft juist voor dat je YAGNI hoog in het vaandel draagt, evenals DRY, en MVVM doen precies wat die 2 termen je vertellen niet te doen.

Overigens lijkt het me niet een voordeel voor een UI framework als je daar ook per se een of ander architecture astronaut pattern voor moet gebruiken.

MVC achtive patterns kunnen leuk zijn, maar die staan los van je UI framework, dus MVVM staat los van of je winforms of WPF gebruikt.

[beany]

EfBe schreef op donderdag 11 maart 2010 @ 13:07:
[...]

die 'rare' gevallen zijn niet zo 'rare' maar vrij vaak voorkomend. In .NET 4 is het opgelost, maar dat is nog niet uit, en duurt ook nog wel even voordat het op ieders PC staat.

Vrij vaak voorkomend valt mee. Ik werk elke dag met WPF en zie het alleen in bepaalde situaties.

[...]

2008? Mja, ik weet niet wie je voor de gek wilt houden, maar WPF designers crashen nog steeds, wel minder vaak na Sp1 voor 2008, maar nog steeds. Met winforms heb ik nooit een crash.

Ik werk elke dag met 2008 SP1, en elke dag met WPF. En ik zie niet echt crashes. Zeldzaam eigenlijk. Misschien paar keer per maand. Geen idee wat jij doet waardoor je de IDE laat crashen, maar onze applicatie met honderden xaml files(welliswaar verspreid over een aantal assemblies) is prima handelbaar in de IDE. Dus ja, misschien doe je iets raars of zo??

[...]

Ik zei ook 'line of business applications'. Geen mediaplayer, maar applicaties met grids, input velden etc. het 'saaie' werk.

Juist dat 'saaie' werk is heerlijk in WPF op te lossen. Met DataTemplates, databinding(wat in WPF vele malen beter is dan in WinForms) en je domain modellen gaat het razendsnel.

[...]

Dat je scaling niet noemt...

Het lijstvoorbeeld is wel een aardige, maar dat is te counteren met grids en het grote scala beschikbare controls en voorbeelden. Ook is het nog maar afwachten wat MS gaat doen met WPF, aangezien Silverlight zo langzamerhand net zoveel begint te kunnen.

Mijn ervaring is juist dat ik regelmatig het probleem had dat een standaard control die je kon vinden(vaak geen source bij) net niet het geen kon wat de ontwerpers wilden. Met WPF kan je relatief eenvoudig je eigen grids/lijstjes/controls maken die precies het geen doen wat jij/ik/de ontwerpers willen.

WPF en Silverlight groeien steeds meer naar elkaar toe, wat goed is. 'Vroeger' zat er nog een aanzienlijk verschil in. We gaan de kant op dat je 1 project hebt die je zowel naar WPF als Silverlight kan deployen. Al blijft veel afhankelijk van de data access uiteraard(vanuit WPF(of gewone .Net app) kan je direct data sources benaderen en vanuit Silverlight zal je met WCF RIA aan de slag moeten, of webservices).

[...]

Waarom zou dat normaliter niet kunnen, dan? Jij moet een apart view-model maken, zonder enige reden, anders dan 'stel je voor dat'. Agile schrijft juist voor dat je YAGNI hoog in het vaandel draagt, evenals DRY, en MVVM doen precies wat die 2 termen je vertellen niet te doen.

Overigens lijkt het me niet een voordeel voor een UI framework als je daar ook per se een of ander architecture astronaut pattern voor moet gebruiken.

MVC achtive patterns kunnen leuk zijn, maar die staan los van je UI framework, dus MVVM staat los van of je winforms of WPF gebruikt.

Klopt in principe wel, echter leent WPF zich er uitstekend voor om de UI volledig te scheiden van de logica dankzij het uitstekende binding mechanisme. Ik hoef geen rare fratsen uit te halen. In ons project heeft geen enkele xaml(user controls, datatemplates etc) code behind. De volledige UI(letterlijk het geen dat de gebruiker ziet) kan zo overboord worden gegooid en er kan een nieuwe UI gemaakt worden door ontwerpers zonder dat dit de logica raakt. Ook is het erg eenvoudig om unit tests er op los te laten. Alle unit tests roepen de viewmodels aan, zonder ook maar 1 user control te raken terwijl wel alle business rules worden getest.

Misschien heb ik vroeger niet zo goed opgelet, maar ik zou zo 123 niet weten hoe je dit goed en relatief snel onder winforms kan opzetten. Enlighten me??

Tevens merk ik ook een voorkeur voor Winforms bij jou. Niks mis mee, ieder zijn ding

[Flard]

Ik zou zelf bij applicaties die met name door particulieren ('voor de hobby') gebruikt worden neigen naar WPF. Net als bij applicaties waar het uiterlijk erg belangrijk is (met name dashboard-achtige applicaties, of applicaties die anderszins full screen draaien).

Voor het gros van de bedrijfsapplicaties voldoet Windows Forms in mijn ogen beter. Mensen die bedrijfsmatig met een applicatie werken, willen gewoon een efficiënte applicatie zonder al te veel poespas. Door standaard .NET-controls te gebruiken weet je dan ook zeker dat je applicatie toegankelijk is (bijv. ook zonder muis) en is de leercurve over het algemeen laag. (Ze moeten nog wel de werking leren, maar niet meer de GUI).

Mij lijkt dat Microsoft ook allebei zeker nog wel een tijd zal supporten...

[EfBe]

beany schreef op donderdag 11 maart 2010 @ 13:40:
[...]
Vrij vaak voorkomend valt mee. Ik werk elke dag met WPF en zie het alleen in bepaalde situaties.

Na sp1 heb ik het intensief bekeken maar ik kwam het veelvuldig tegen, en ben toen weer winforms gaan gebruiken.

Ik werk elke dag met 2008 SP1, en elke dag met WPF. En ik zie niet echt crashes. Zeldzaam eigenlijk. Misschien paar keer per maand. Geen idee wat jij doet waardoor je de IDE laat crashen, maar onze applicatie met honderden xaml files(welliswaar verspreid over een aantal assemblies) is prima handelbaar in de IDE. Dus ja, misschien doe je iets raars of zo??

Mijn ide crasht nooit, tenzij ik iets met wpf doe, dan gaat hij soms onderuit. Erg irritant. Winforms is zeker niet zaligmakend, laat dat duidelijk zijn, en als je from scratch met iets moet beginnen, dan is wpf wellicht de beste keuze want je moet toch het framework leren, maar hou wel rekening met slechtere tools, een kleiner aanbod controls, minder articles etc. Overigens hoor ik van anderen ook dat hun ide's crashen ivm wpf, niet dagelijks, maar wel regelmatig.

[...]
Juist dat 'saaie' werk is heerlijk in WPF op te lossen. Met DataTemplates, databinding(wat in WPF vele malen beter is dan in WinForms) en je domain modellen gaat het razendsnel.

Databinding in winforms werkt prima, je moet alleen weten wat je doen moet, en dat is met WPF niet anders: ook daar moet je werk verrichten en met dingen rekening houden. Onze nieuwe designer werkt met winforms en is compleet observer driven, omdat alles undo/redo aware is gemaakt. Via databinding is met weinig code veel productiviteit te halen, en het werkt ECHT wel goed. Ik schold vroeger ook op winforms databinding, maar het bleek gewoon dat ik niet doorhad hoe je het goed moet gebruiken. Met dependency properties en wat al niet meer heb je bij WPF hetzelfde: de basic troep werkt prima outofthebox, maar indien je iets complexere dingen gaat doen moet je ook daar opletten, net als bij winforms.

De fantastische geluiden die ik uit jouw posts opmaak hoorde ik vroeger ook over winforms hoor, en daarvoor over ATL, MFC etc. het is altijd prachtig, totdat je buiten de paden gaat, en dan moet je wel iets doen, dat is bij ieder framework zo, ook bij WPF.

[...]
Mijn ervaring is juist dat ik regelmatig het probleem had dat een standaard control die je kon vinden(vaak geen source bij) net niet het geen kon wat de ontwerpers wilden. Met WPF kan je relatief eenvoudig je eigen grids/lijstjes/controls maken die precies het geen doen wat jij/ik/de ontwerpers willen.

Mja, ik weet niet wat voor applicatie jij maakt, maar een line of business applicatie moet zo saai en zo voorspelbaar mogelijk zijn: dus zo dicht bij windows zitten als mogelijk. Geen fratsen, dat snapt de information worker niet. In winforms kan dat net zo goed. Wil je een special combobox? class deriven, paar regels code, klaar. Komt in de toolbox, sleur/pleur en je control zit op een form.

[...]
Klopt in principe wel, echter leent WPF zich er uitstekend voor om de UI volledig te scheiden van de logica dankzij het uitstekende binding mechanisme. Ik hoef geen rare fratsen uit te halen.

In winforms ook niet. Totdat je iets complex gaat doen en dat is bij wpf precies eender. Als een property wijzigt in code dan zal je toch iets moeten raisen wil wpf doorhebben dat die value wijzigt.

In ons project heeft geen enkele xaml(user controls, datatemplates etc) code behind. De volledige UI(letterlijk het geen dat de gebruiker ziet) kan zo overboord worden gegooid en er kan een nieuwe UI gemaakt worden door ontwerpers zonder dat dit de logica raakt. Ook is het erg eenvoudig om unit tests er op los te laten. Alle unit tests roepen de viewmodels aan, zonder ook maar 1 user control te raken terwijl wel alle business rules worden getest.

De UI logica zit echt ergens, is het niet in de code behind dan wel in een class die het managet. BL logica hoort niet in de UI, maar wat heeft dat met MVVM te maken? Een UI control die een event handler heeft die een BL method aanroept kan in iedere UI layer, met of zonder pattern.

Misschien heb ik vroeger niet zo goed opgelet, maar ik zou zo 123 niet weten hoe je dit goed en relatief snel onder winforms kan opzetten. Enlighten me??

Les 1 van software engineering: ook vroeger was men prima in staat om geweldige software te maken. De moraal van het verhaal is: met hype-of-the-day patterns als MVVM kun je wellicht iets maken, maar het is niet noodzakelijk om iets te doen met UIs en gescheiden lagen. Dat kon vroeger ook al, simpelweg door de code niet in de eventhandlers te prakken maar netjes gestructureerd te programmeren. Tegenwoordig moet een groep programmeurs daar per se een pattern voor gebruiken en dan ook nog 1 die nieuw is, anders gaat het kennelijk niet werken. Tja.

Tevens merk ik ook een voorkeur voor Winforms bij jou. Niks mis mee, ieder zijn ding

Ik ga ooit wel naar WPF kijken voor de 2e keer, het punt is alleen dat ik al vele jaren winforms doe en het ken als mn broekzak. Ook heb ik in de jaren daarvoor geleerd dat wat men je ook op de mouw speldt: een UI framework heeft altijd een 'dark side' en zolang je die niet kent is het een framework dat je alleen maar tijd kost: of dat nou winforms, WPF, silverlight, flash, ASP.NET, curses, Win32, MFC, VCL, X11 of wat voor frameworks men allemaal verzonnen heeft om UIs in te maken: je komt een heel eind, maar hou rekening met pitfalls die je veel tijd en dus geld gaan kosten, en wellicht je dwingen om dingen opnieuw te doen. Voor de topicstarter dus wel iets om rekening mee te houden, wat er ook gekozen wordt. Is er al kennis van een bepaald framework in huis, dan is het wellicht nuttig om daar op voort te borduren omdat je dan minder risico loopt voor pitfalls en dus geldverlies.

Want de consultant die wat artikeltjes online schrijft over <framework X> betaalt die verloren tijd niet, dat doe je zelf.

[beany]

Ik heb blijkbaar iets gemist bij WinForms databinding. Ik heb het altijd gehaat!

Ik heb inmiddels ook redelijk wat frameworks achter de rug. En ik ken inderdaad de verhalen dat ze stuk voor stuk geweldig zijn. En inderdaad bleek het vaak niet zo mooi te zijn, of de verwachtingen waren misschien te hoog.

WPF is het eerste framework waarbij ik het gevoel heb dat het echt werkt. Tuurlijk moet je weten wat de grenzen zijn, maar dat is met elk framework zo. En uiteraard heeft het zijn rariteiten. Maar zoals ik al zei: dit is het eerste framework waarbij ik het gevoel heb dat het doet wat het beloofd!

Probleem is wel dat het flink anders is dan WinForms. Mocht je er weer naar gaan kijken: trek er wat tijd voor uit!