Jak powinno się korzystać z wpf?

Witam mam pytanie ponieważ trochę już programuje sobie w wpf ale mam pewne pytanko odnośnie jak to powinno w nim być ponieważ widziałem ze w wpf dużo używa się mvvm nie wiem jak to do końca działa ale słyszałem ze żeby w pełni wykorzystać możliwości wpf to trzeba to umieć i własnie mam co do tego pytanie jak to z tym jest czy mvvm jest tak bardzo konieczny żeby używać wpf? I przy okazji będąc przy tym mam pytanie ponieważ ja nazywam czasem kontrolki bo ułatwia mi to programowanie w tym ale czy tak powinno się robić żeby się je nazywało czy może jakoś przez jakieś funkcje get set powinno się to robić ?

Pisanie w WPF bez MVVM to masochizm. Poczytaj o Prism.

grzesiek51114 napisał(a):

Pisanie w WPF bez MVVM to masochizm. Poczytaj o Prism.

Mam wrażenie, że bez znajomości podstaw WPF, pisanie w MVVM też będzie porażką. ;)

GironX napisał(a):

grzesiek51114 napisał(a):

Pisanie w WPF bez MVVM to masochizm. Poczytaj o Prism.

Mam wrażenie, że bez znajomości podstaw WPF, pisanie w MVVM też będzie porażką. ;)

Bzdura, nawet program konsolowy może być napisany w MVVM. WPF to tylko technologia. ;)

MVVM to paradygmat jak każdy inny, można go używać lub nie.
WPF nie wymaga do szczęścia MVVM, ale MVVM ma swoje zalety i dlatego się go używa.
Spróbuj poczytać o bibliotece MVVM Light, to dobre wprowadzenie do tej technologii.

Sparzyłem się MVVM przy pierwszym kontakcie, dlatego w moim przypadku, stwierdziłem, że lepiej będzie jeśli złapię podstawy WPF i dopiero wtedy zajmę się MVVM.

Nie odsyłajcie go do Prism, jak nie zna podstaw.

Prosty przykład (nie 100%), jak to powinno mniej więcej wyglądać.
Dajmy na to, że robisz odtwarzacz mp3.

Najpierw musisz zbudować swój model (M). Model to nic innego jak klasy opisujące Twój problem - czyli tu np. modelem będzie plik mp3. W innej aplikacji do modelu mogłaby należeć Osoba, Adres, Klient itp.

A więc model. Przykładowo może to wyglądać tak:

public class Mp3File
{
  public string FileName { get; set;}
  public string Title { get; set; }
  public string Author { get; set; }
}

Klasy modelowe często umieszcza się w osobnym projekcie.

Następnie masz coś takiego jak ViewModel (VM). I tu się dzieje tak naprawdę cała magia związana z widokiem. ViewModel to połączenie między widokiem, a resztą aplikacji - innymi serwisami itd.

Na początek może to wyglądać tak:

public class Mp3ViewModel
{
  public ObservableCollection<Mp3File> Mp3Files { get; set; } = new ObservableCollection<Mp3File>();
}

To tak naprawdę bardzo ułomny ViewModel, ale taki zostawiam dla przejrzystości.

Następnie masz klasę widoku (V) - czyli XAML razem z code behind, np:

public class Mp3View: Window
{
   Mp3ViewModel vm;
  
   public Mp3View(Mp3ViewModel vm)
   {
      this.vm = vm;
      DataSource = vm;
   }
}

To oczywiście bardzo uproszczone, bo Mp3ViewModel tak naprawdę powinien implementować interfejs w stylu IMp3ViewModel i powinien być wstrzykiwany do Mp3View za pomocą dependency injection.
W każdym razie najważniejsze jest to, że ViewModel NIE WIE NIC o widoku, ale wie o modelu. Model NIE WIE NIC o ViewModel ani o widoku (jest totalnym ignorantem). Natomiast widok wie TYLKO o ViewModel, ale nic nie wie o modelu... No, to nie do końca prawda, że widok nie wie nic o modelu, bo musi znać chociaż nazwy pól, żeby sobie bindować :) Ale nie ma żadnych referencji do modelu.

Teraz, cokolwiek robisz na widoku (np. odtworzenie mp3), powinieneś to robić przez komendy (czytaj: wpf + commands).

Komenda jest tworzona w ViewModel. To jest coś jak zdarzenie w WinForms, ale nie do końca. Po prostu po wciśnięciu przycisku PLAY wywołujesz komendę: "PlayDaMadafakinSong" zamiast obsługiwać zdarzenie ButtonClick :)

Komenda dalej w sobie tylko znany sposób odtwarza plik mp3.

Zatem masz tutaj wszystkie elementy wzorca: Model (M), Widok (V), Widok modelu (VM).

Przy czym przypominam, że model powinien być w osobnym projekcie, natomiast view i viewmodel mogą być w tym samym (ale nie muszą). Zależy tak naprawdę od technologii i aplikacji - jak będzie łatwiej/lepiej.

Do poczytania:
wpf + databinding
wpf + command
wpf + IObservable
wpf + ObservableCollection

Nie musi się uczyć całego Prisma. Starczą:

• DelegateCommand oraz DelegateCommand<T>;
• EventAggragator;
• BindableBase.

Bez tego będzie musiał napisać mnóstwo, często dziwnego kodu samodzielnie.
To trochę tak jak w ASP.NET MVC. Masz klasę Controller i początkujący w zasadzie nie musi zastanawiać się jak została zaimplementowana. Stosuje dziedziczenie po niej i kontroler działa. Bez frameworku MVVM klasę implementującą INotifyPropertyChanged będzie trzeba napisać samodzielnie, a po co się męczyć skoro mamy BindableBase? To samo dotyczy komend; skoro masz DelegateCommand to po co zawracać sobie głowę samodzielnym tworzeniem implementacji ICommand, rzecz jasna dużo gorszej?

Wiesz... nie mówię, że to jest złoty środek nauki WPF z MVVM, bo sam uczyłem się bez frameworków. Tylko, że później zdałem sobie sprawę z tego, że wiele razy straciłem mnóstwo czasu implementując oczywistości. ;)

PS: Model to nie tylko klasy opisujące różne rzeczy ale także logika biznesowa, serwisy etc...
PS2: Czy Ty właśnie nie zastosowałeś tutaj podejścia Encja na twarz i pchasz? ;)

Moim zdaniem to jest tak, że wypada poznać/zrozumieć jak się robi rzeczy bez żadnych "wrapperów", czy frameworków. Bo brak takiej wiedzy wychodzi prędzej, czy później. Zresztą wszyscy piszą, że prism do małych aplikacji się nie nadaje, więc dobrym podejściem jest zrobić coś małego bez tego, żeby zrozumieć jak to powinno działać. Później, gdy się użyje np. Prism dużo rzeczy jest jasnych i oczywistych.