WPF a Windows Forms

Witam. Czy ktoś mi wyjaśni różnice pomiędzy Windows Presentation Foundation a Windows Forms? Jaka technologia jest lepsza? Z góry dziękuję.

good question..I wonder too what is the diference..

http://stackoverflow.com/questions/2685150/wpf-or-windows-forms

Czy ktoś mi wyjaśni różnice pomiędzy Windows Presentation Foundation a Windows Forms?

Yhh... różnice są spore.

Jaka technologia jest lepsza?

Zależy do czego. WinForms jest łatwiejsze. Jest bardziej klasyczne, więc jest lepszym wyborem do zwykłych okienkowych aplikacji w starym stylu, bez bajerów.
WPF jest z założenia bardziej „nowoczesne” i „multimedialne”. Jest cięższe, co ma wpływ na wydajność jeśli program ma działać na starych bardzo słabych komputerach.
WPF ma problemy z jakością renderowania fontów - Microsoft od paru lat zlewa na jakość tekstu, co widać też np. w najnowszych wersjach IE i Office'a.

W praktyce w obu bibliotekach da się zrobić to samo - tylko różna jest droga do celu.

Windows Forms ma niższy próg wejścia. Domyślnym sposobem ustawiania kontrolek jest Drag&Drop. Ma też sporo narzędzi do rzeźbienia bezpośrednio na bazie danych.
Wygrywa w tworzeniu aplikacji w architekturze Nike albo architekturą Shia LaBeouf (just do it).
W przypadku gdy aplikacja ma mieć niebanalny wygląd, albo ma być pokryta testami automatycznymi (czy to ze względu na złożoność czy wymagania formalne) w ślepo wybrałbym WPF.

Moim skromnym zdaniem projektowanie interfejsu przy wykorzystaniu WinForms jest o wiele łatwiejsze i intuicyjne. Tworzenie tego samego w WPF bywa uciążliwe i XAML jakoś do mnie nie przemawia - co nie znaczy, że tego nie umiem. Po prostu jakoś nie przepadam. Jednakże dla mnie istotnym jest to, że z WPF'em wiąże się wykorzystanie wzorca MVVM. Od razu podepnę się pod temat i czekam na odpowiedzi. Ostatnio jeden z programistów stwierdził mi, że do WinFormsów najlepiej pasuje MVP. Nie jestem tak biegły we wzorcach architektury i chciałbym się dowiedzieć co stoi na przeszkodzie by wykorzystać MVVM ? On niestety po tym pytaniu odpowiedział "bo tak o". Ja jednak jak czegoś nie wiem to nie udaje mądrego, więc chciałbym się was zapytać bardziej doświadczeni.

Databinding w Windows Forms jest nastawiony na współpracę z obiektami ADO.Net (DataSet i DataTable). Osobiście nawet binding do obiektu innego umiem zrobić tylko z kodu C#, nawet nie wiem czy da się to zrobić z Designera. W czasie gdy w WPF grubo ponad połowa Bindingów wygląda następująco
WlasciwoscKontrolki="{Binding WlasciwoscObiektu}"
No i na koniec Visual Studio z Resharperem wskaże ci z miejsca że zrobiłeś literówkę w nazwie właściwości. W Windows Forms nawet nie wiem czy błąd zostaje zgłoszony podczas działania aplikacji.

WinForms jest dobre dopóki chcesz korzystać z gotowych kontrolek
Gdy tylko będziesz miał jakieś nietypowe wymaganie co do kontrolki to w winforms będziesz sobie to musiał sam zaimplementować najczęściej rysując połowę kontrolki od zera a w wpf po prostu wsadzasz jedną kontrolkę w drugą i ją stylujesz
wpf jest bardziej podobny do htmlowego stylu pisania - doświadczenie z projektowania stronek może się trochę przydać

szogun1987 napisał(a):

Windows Forms ma niższy próg wejścia. Domyślnym sposobem ustawiania kontrolek jest Drag&Drop. Ma też sporo narzędzi do rzeźbienia bezpośrednio na bazie danych.
Wygrywa w tworzeniu aplikacji w architekturze Nike albo architekturą Shia LaBeouf (just do it).

WPF też pozwala na drag & drop i pisanie kodu w handlerach zdarzeń, zamiast zgodnie z MVVM. W WinFormsach z kolei stosowanie dobrej architektury nie jest zakazane.

mariano901229 napisał(a):

Jednakże dla mnie istotnym jest to, że z WPF'em wiąże się wykorzystanie wzorca MVVM. Od razu podepnę się pod temat i czekam na odpowiedzi. Ostatnio jeden z programistów stwierdził mi, że do WinFormsów najlepiej pasuje MVP. Nie jestem tak biegły we wzorcach architektury i chciałbym się dowiedzieć co stoi na przeszkodzie by wykorzystać MVVM ? On niestety po tym pytaniu odpowiedział "bo tak o". Ja jednak jak czegoś nie wiem to nie udaje mądrego, więc chciałbym się was zapytać bardziej doświadczeni.

WPF ma widoki w XAMLu i deklaratywne bindingi, dlatego wygodnie i ładnie można w nim powiązać View i ViewModel. W przypadku WinFormsów, w których kod widoku to normalny kod C# nie będzie to już tak ładnie wyglądało, a do tego trzeba byłoby dopisać sporo kodu bindującego, więc lepiej już zastosować wzorzec MVP, w którym nie ma tyle magii.

szogun1987 napisał(a):

Databinding w Windows Forms jest nastawiony na współpracę z obiektami ADO.Net (DataSet i DataTable). Osobiście nawet binding do obiektu innego umiem zrobić tylko z kodu C#, nawet nie wiem czy da się to zrobić z Designera.

Oczywiście, że się da, wystarczy wybrać Object zamiast Database przy tworzeniu DataSource. Ja tak zawsze robiłem, bo dla mnie łączenie kodu GUI z DAL to jakaś projektowa patologia.

No i na koniec Visual Studio z Resharperem wskaże ci z miejsca że zrobiłeś literówkę w nazwie właściwości. W Windows Forms nawet nie wiem czy błąd zostaje zgłoszony podczas działania aplikacji.

Przecież to jest normalny kod C#, błędny kod się nawet nie skompiluje.

w WPF można zmienić globalnie zachowanie data bindingu tak żeby w debug się od razu wywalał przy błędnym bindingu
Nie bardzo na etapie kompilacji się da to wykryć bo bindingi są bardzo elastyczne - można tam podłożyć podczas działania programu dowolną klasę, w tym dynamiczną na zasadzie duck typingu

w WinForms bindowanie działa dziwnie - w ogóle nie zwraca uwagę na PropertyName w przypadku zdarzenia OnPropertyChanged - po prostu po otrzymaniu tego zdarzenia odświeża wszystkie bindowania
To oznacza że jeśli mamy 10 kontrolek podpiętych i chcemy na naciśnięcie przycisku zmienić 3 property w podpiętej klasie gdzie w każdej mamy na setterze OnPropertyChanged to po każdym setterze bindingSource odpyta o stan każdego innego properta - w rezultacie gettery zostają wywołane w sumie 30 razy (!) zamiast 3. Gdy mamy jakąkolwiek logike na getterach to może wpłynąć na płynność działania aplikacji.
Już nie mówię o tym że podczas ładowania formy gettery potrafią się wywoływać po kilka razy na każdym propercie, a bindingSource losowo postanawia odświeżyć obiekt wywołując setter na każdym propercie na znaną mu wcześniej wartość (zazwyczaj tę samą ale bez sprawdzenia if (value != currentValue) to wywołuje automatycznie OnPropertyChanged i i znów lawinę getterów)