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ć ?
C# 
- Rejestracja:ponad 11 lat
- Ostatnio:ponad 4 lata
- Postów:2442
0
Pisanie w WPF bez MVVM to masochizm. Poczytaj o Prism.
- Rejestracja:około 10 lat
- Ostatnio:ponad 2 lata
- Postów:59
0
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ą. ;)
- Rejestracja:ponad 11 lat
- Ostatnio:ponad 4 lata
- Postów:2442
0
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. ;)
GironX
Z pewnego punktu widzenia wszystko jest technologią. ;)
- Rejestracja:około 10 lat
- Ostatnio:ponad 2 lata
- Postów:59
0
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.
ponieważ trochę już programuje sobie w wpf Wydaje się, że OP podstawy WPFa już zna ;)
- Rejestracja:około 22 lata
- Ostatnio:około miesiąc
- Postów:5042
1
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
- Rejestracja:ponad 11 lat
- Ostatnio:ponad 4 lata
- Postów:2442
0
Nie musi się uczyć całego Prisma. Starczą:
DelegateCommandorazDelegateCommand<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? ;)
edytowany 3x, ostatnio: grzesiek51114
@grzesiek51114 Możesz mi polecić jakieś dobre źródło informacji o MVVM?
@GironX: w zasadzie wszystko fajnie opisane: https://prismlibrary.github.io/docs/wpf/Introduction.html
@grzesiek51114 Super, dziękuję.
- Rejestracja:około 22 lata
- Ostatnio:około miesiąc
- Postów:5042
1
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.