Czy WinForms już jest niemodne?

Witam

Od dłuższego czasu czytam strony poświęcone WPF i na każdej z nich autorzy opisują że Windows Forms już jest niemodne, jednakże 90% aplikacji jakie widzę to właśnie WForms, jak Wy się na to zaopatrujecie?

jak Wy się na to zaopatrujecie?
Że znacznie łatwiej jest zbudować prawidłowy interfejs w WinForms, niż w WPF.

WPF vs WinForms to coś jak LaTeX vs Word: niby to pierwsze ma ogrooomne możliwości, ale na każdym kroku problem i pół godziny góglania. A i tak rozwiązanie nie jest zadowalające, a próbują ci wmówić, że „tak ma być”.

Ze strony Azareina rozumiem, że WForms jest modny, w miarę prosty ( prostszy niż WPF ) i że ciągle stosowany.

Co do filmiku nerf, ciekawe zjawisko, nieraz doświadczyłem tego w Windows Forms.

Chyba nie można jednoznacznie powiedzieć, że windows forms jest już nie modny. WPF jest po prostu mocniejszy? Więc używa się ich według tego co się chcę osiągnąć.
Jakieś proste apki WF a kombajny WPF. Z tego, że w WPF ujednolicono cały model programowania wszystko masz w nim razem muzyka,grafika,rysowanie,kontroli a w WF rozrzucone na WF,GDI+,API Directx,api wmp.

WF jest stosowany z dwoch powodow:

1. Programy napisane w WF nie oplaca sie przenosic na WPFa
2. Nie oplaca sie przenosic na nowe nieznane technologie

dlatego WF jest taki modny

Witam wszystkich!

Swoją przygodę zaczynałem w C# oczywiście od WinFormsów. Rzeczywiście na początku jest euforia, moc możliwości i różnych pierdółek do ustawiania. Gdy opanowałem podstawy, zająłem się poważniejszym projektem, w tym przypadku "My Organiserem" (być może ktoś pamięta, temat miał w końcu 1600 wejść).

Rzecz, która mnie jednak zniechęciła do WinFormsów było brak dowolności ustawiania pożądanego wyglądu. Prosty przykład: chciałeś mieć ładny przycisk z opcją zaokrąglania i gradientem? O nie panie, nie ma mowy, musisz albo przeciążyć klasę i zajmować się pisaniem tych funkcjonalności lub szukać jakichś kontrolek w internecie (z których sporo nie działa, przerabiałem to). Była to bariera z którą nie mogłem sobie za bardzo poradzić więc... postanowiłem nauczyć się WPF.

Początek był trudny - kompletnie nie mogłem zrozumieć filozofii przypinania danych do kontrolek oraz ustawiania schematów elementów. Było jednak coś, co zachęcało mnie do dalszej nauki: OGROMNE możliwości ustawiania wyglądu każdej części kontrolki. Gradienty to już nie problem. Chcesz mieć CheckListBox z podświetlanymi elementami na różowo? Nie ma problemu. A może DataGridView, gdzie komórka będzie miała gradient? Jasne! I spróbujcie teraz coś takiego zrobić w WinFormsach :)

Obecnie, w trakcie pisania My Organiser 2.0 korzystam z WPF i wniosek mam następujący - WinFormsy są fajne na początek ale w praktyce mało konfigurowalne (przynajmniej z poziomu "design") i mało wydajne (efekt migających kontrolek i te sprawy). WPF zapewnia wydajność, duże możliwości dostosowania wyglądu (dzięki wykorzystaniu XAML'a), łatwość przypinania danych do kontrolek. Może rzeczywiście nie jest to materiał łatwy do przyswojenia ale opłaca się - uwierzcie mi :)

Pozdrawiam! AlfaLeporis

Dokładnie masz rację, ja po opanowaniu WF i MVC i innych typu Singleton ( z rodziny Creational etc ) biore się za MVVM i WPF. Mam już małą bazę i walczę z interfejsem.

Pozdrawiam

A może DataGridView, gdzie komórka będzie miała gradient? Jasne! I spróbujcie teraz coś takiego zrobić w WinFormsach

Oczywiście że się da, tylko nie ma gotowca i trzeba rysować kontrolkę samemu...
Tak, WPF wygrywa pod względem graficznych bajerów.
Ale z jakiegoś powodu, w samym VS jest znacznie więcej różnych kontrolek dla WinForms niż WPF...

Azarien warto pisać małe aplikacje bazodanowe oparte o WPF ( tym samym się go uczyć ) czy lepiej drążyć WF. Wiadomo, że na moje potrzeby programistyczne aplikację są raczej nie wielkie, dopiero w firmach zaczyna się prawdzie programowanie.

Ależ ja nie mówiłem że się nie da (chyba że to tak zabrzmiało) - da się ale o wiele większym kosztem niż w WPF gdzie wystarczy dodać kilka linii w XAML'u.

Co do ilości kontrolek - owszem, ale popatrz na ten przykład: w WinFormsach jest coś takiego jak checkListBox, w WPF natomiast nie ma czegoś takiego. Można by powiedzieć: "Schrzanili sprawę, toż to jest przecież niemal podstawowa kontrolka". Nic bardziej mylnego, do stworzenia checkListBoxa w WPF'ie wystarczy dodać ListBoxa i zmodyfikować szablon Itema na CheckBox'a - sumując jest to 5 dodatkowych linii kodu w XAML'u. Po co więc niemal powielać kontrolki?

Do WinFormsów jest masa kontrolek zewnętrznych firm (Telerik, DevExpress, itp.), które pozwalają osiągnąć wypasione efekty graficzne i zapewniają znacznie większą konfigurowalność niż standardowe. Efekt nie jest wcale dużo gorszy niż WPF.
WinFormsy są i długo będą popularniejsze, bo są starsze, więc więcej aplikacji powstało w tej technologii. Z kolei nowsze programy coraz częściej są tworzone w WPF.
A tak w ogóle, to w porównaniu z webowymi frameworkami .NET, obie te technologie są mało popularne. ;P

Tak naprawdę obie biblioteki od paru lat stoją w miejscu. Microsoft nie potrafi chyba się zająć więcej niż jedną na raz, a ostatnio było to WinRT...

Miałem napisaną aplikację, dość rozbudowaną w WinForms z wykorzystaniem komercyjnych bibliotek, po czasie stwierdziłem, że może warto przepisać GUI na WPF, a jeszcze lepiej Silverlight. Po ok 3 miesiącach zwątpiłem. Produktywność dostępnych kontrolek jest dużo większa dla technologii WF niż dla WPF/Silverlight. Inaczej ujmując trzeba się kilkukrotnie więcej napracować, żeby osiągnąć interfejs o takim samym stopniu skomplikowania, a korzyści żadnych odczuwalnych nie zauważyłem. W komercyjnych bibliotekach WF dostępne są skórki, czyli zestawy gotowych tematów profesjonalnie przygotowanych co znacznie poprawia wygląd aplikacji, praktycznie bez żadnego nakładu pracy. Dodatkowo można skórki edytować i tworzyć nowe. Wiem, że WPF ma większe możliwości pod tym względem, ale w ogromnej większości problemów WF w zupełności wystarcza. Osobnym tematem jest to co przyniesie przyszłość, WPF/Silverlight miało być rozwiązaniem na lata, teraz MS znów promuje WinRT nie rozwijając poprzednich technologii, a wręcz powoli się z nich wycofuje (Silverlight), a szkoda.

Raczej nie warto mówić o wyższości jednej technologii nad inną. Nie wiem jak inni, ale ja osobiście trafiam na jedno zlecenie w wpf, na 20/30 w winforms. Często na anglojęzycznych stronach w tematach "czy warto?" odnośnie wpf, w odpowiedziach pojawia się : "steeper learning curve" i to właśnie jest powodem takiego podejścia do tej technologii. Osobną (ale ważną) sprawą jest też podejście microsoftu, gdzie nikt nie zna dnia ani godziny, kiedy powiedzą, że wsparcie dla WPF zostaje zakończone (albo wyskoczą z jakąś (ich zdaniem) świetną nową technologią).

To jest właśnie bolączka Microsoftu, że średnio raz na dwa lata zmienia się kierunek wiatru.

Dlatego lepiej olać ich marketingowy bełkot i trzymać się tego co już jest i działa. A działać będzie (bardzo) długo, dla przykładu: runtime Visual Basic 6 (jeszcze nie .Net) ma oficjalny support do 2023 roku.

Niby to wycofany Silverlight też będzie jeszcze wspierany długo.

Ja ostatnio miałem propozycję wzięcia udziału w nowym projekcie tworzonym w WinFormsach. Coś mi się zdaje, że ta technologia prawdopodobnie przeżyje WPFa.

Warto byłoby po ponad roku odświeżyć sporo temat.
Ciekawe byłyby także ponowne wypowiedzi ludzi, którzy wcześniej brali udział w dyskusji, czy ich zdanie się zmieniło.

Wydaje się, że mimo wszystko świat powoli odchodzi od WF na rzecz WPF.

Choć może wydać się to zaprzeczeniem mojego zdania powyżej, to napiszę: obecnie w firmie komercyjnie piszemy nadal w WF, lecz tylko i wyłącznie ze względu na to, że dużych projektów nie opłaca się przepisywać. Każdy nowy projekt od razu startuje w WPF, nie ma sensu brnąć w WF. Nawet, jeżeli początkowo wydaje się, że aplikacja nie musi być atrakcyjna wizualnie (sic! każda musi być! to jest marketing). W przyszłości klient zażyczy sobie gdzieś gradient i już nic się nie zrobi, bo przecież przepisanie WF->WPF będzie nieopłacalne. Warto patrzeć w przyszłość.

Dodatkowych kontrolek obecnie także jest więcej dla WPFa niż WFa.

Reasumując: zaczynacie? startujcie w WPF. Nie myślcie o WF. To, że dla WF są nadal ogłoszenia o pracę, oznacza tylko, że potrzeba ludzi do starych projektów. W takiej pracy na pewno się nie rozwinie człowiek.

Wydaje się, że mimo wszystko świat powoli odchodzi od WF na rzecz WPF.
Świat w ogóle odchodzi od dekstopa na rzecz telefonów, tabletów i takich tam, a nawet na desktopie coraz więcej rzeczy jest robionych webowo. Tendencja utrzymuje się od lat, i moje niezadowolenie z tego stanu rzeczy nie ma żadnego wpływu na rzeczywistość ;-)

Każdy nowy projekt od razu startuje w WPF, nie ma sensu brnąć w WF
Ja często nie widzę sensu „brnąć” w WPF. Nie lubię go bo jest czasochłonne.

W ktorym momencie WPF jest bardziej czasochlonny niz WF ?
Chyba podstawowa zaleta WPF to ze renderuje okienka na GPU a nie CPU, przy rzeczach typu zwykly edytor map 2D to zaczyna odgrywac role.
W WPF mamy tez o niebo lepszy binding, w WF to jest tragiczne. W WPF na gridach mozna robic samoskalujace sie okienka bardzo latwo.
Poza tym templaty i MVVM(ja tam go lubie).

Warto uczyć się WPF zamiast WP.
Tak jak napisał Amphhh, duża zaletą są templaty oraz duże wsparcie dla MVVM.

Nawiązując do posta Azarien.
Korzystając z WPF i tworząc z duchem MVVM, zawsze będzie nam się łatwiej przerzucić na Angulara i inne rozwiązania webowe które wspierają MVVM.

Ja dodam od siebie, ze oczywiscie web + mobilki przewazaja. Natomiast "biznesowe swinie" sa pisane i beda pisane jako aplikacje desktopowe na PC'ty, bo maja sluzyc do pracy i w pelni wykorzystywac mozliwosci obliczeniowe maszyny. Do tego klienci chca miec ladny, nowoczesny interfejs i tutaj WPF w pelni zdaje egzamin, do tego jest bardzo elastyczny. Dodam, ze WPF to przede wszystkim XAML, a polityka Microsoftu zmierza do tego, ze nie bedzie rozroznienia Windows Phone/Windows.Bedzie po prostu Windows (zarowno na PC i na urzadzenia mobilne) i ta sama aplikacja bedzie uruchamiana zarowno na urzadzeniu mobilnym jak i na PC. Wiec warto znac WPF przynajmniej dla samego XAML'a.