Przesiadka na z PHP na c#

Witam

Po 7 latach zawodowego programowania w php planuje przesiąść sie na tworzenie aplikacji desktopowych w c# na widowsa.
Ciekawy jestem jakie aktualnie są standardy tworzenia aplikacji.

Na tą chwilę dobrze ogarniam WindowsForms, wątki, delegaty, eventy, interfejsy Ienumerable, IComparable itd itd... tak więc c# mogę powiedzieć ze jest mi znany.
Jednak jakich wymagań mogę się aktualnie spodziewać na stanowisku programisty c# ?

Chciałbym uniknąć programowanie aplikacji www bo już mi to zbrzydło - Także wymagania głównie na apki desktopowe.

Pozdro ;)

Jak na desktop, to chyba lepiej iść w WPF, bo WF jest już dość przestarzały.

somekid - czy firmy wymagają MVVM na apki desktopowe ?
Czy to raczej jesst wymagane np w tworzeniu apek na telefon ?

Z tego, co się orientuję, to dla WPF wzorzec MVVM to raczej podstawa. Nigdy nie pracowałem w tej technologii, ale kilka razy się rekrutowałem i zawsze MVVM wymagali.

Jak masz doświadczenie w web to może rozważ ASP.NET. Co do desktopów to tak, WPF i MVVM.

somekind napisał(a)

Z tego, co się orientuję, to dla WPF wzorzec MVVM to raczej podstawa.

I to prawda. Pisanie aplikacji w WPF bez mvvm to naprawdę katorga. Po wdrożeniu się w mvvm wzorzec ten potrafi odpłacić się zaletami jakich w WF próżno szukać. Jak najbardziej jest to podstawa.

grzesiek51114 napisał(a):

Po wdrożeniu się w mvvm wzorzec ten potrafi odpłacić się zaletami jakich w WF próżno szukać. Jak najbardziej jest to podstawa.

Przecież mvvm to wzorzec, więc można go zastosować w różnych technologiach. Również w WF, więc wyjaśnij mi bardziej swoją wypowiedź.

Juhas napisał(a)

Przecież mvvm to wzorzec, więc można go zastosować w różnych technologiach

Tak wiem, ale MS w całej swojej wspaniałości stworzył technologię od razu przystosowaną do MVVM. To tak jak z ASP gdzie jest czyste WebForms i jest MVC. W WPF nie tworzy się widoku imperatywnie tak jak ma to miejsce w WF. Tworzy się XAML, do którego binduje się dane i komendy wykorzystując ViewModel i nie operując bezpośrednio na kontrolkach tylko na zwykłych kolekcjach czy obiektach. Nie trzeba grzebać wewnątrz datacontekstu kontrolki żeby dogrzebać się do kolekcji, z której korzysta, dajmy na to ComboBox. Zamiast grzebania taka kolekcja jest od razu własnością ViewModel'u i ma się do niej bezpośredni dostęp. Daje to bardzo duże korzyści, bo tak naprawdę program nie potrzebuje GUI do działania :) O ile wiem w WF raczej stosuje się MVP ale gołe WinForms w stosunku do WPF z MVVM jest raczej mało wygodne. Za to na gołym WPF można korzystać z bindowania danych tak jak w MVVM tylko wszystko wtedy siedzi w code-behind, razem z logiką widoku. W WinForms nie ma za to tak wygodnego bindowania danych i komend jak w WPF.

WPF, WF, asp.net WebForms, asp.net mvc to tylko frameworki warstwy prezentacji, pozostała część aplikacji powinna być od nich kompletnie niezależna bez względu na to który z nich wybierzemy i czy użyjemy "podstawowego" wzorca warstwy prezentacji wciskanego z danym frameworkiem czy nie.

Projekt może być dobrze napisany i przyjemny w utrzymaniu w każdym z nich, bo tak samo jak się zdarzało trafiać na projekty z logiką biznesową pisaną w codebehind w WF i Webformsach, tak samo można trafić na projekty z logiką biznesową pisaną w ViewModelach w WPF MVVM, czy Controlerach w Asp.net MVC. Bez odpowiedniego "Separation of concerns" w każdym z nich można stworzyć kupę, a z odpowiednim Soc nawet ładny drapacz chmur :P

WPF = WTF, na prawdę w niektórych sytuacjach to działa jak chce.