View i ViewModel się zbyt duża

Question

Dodając dodatkową funkcjonalność do głównego widoku mam w mojej aplikacji, mam sobie sprawę, że ilość kodu wkrótce stać się problemem (obecnie około 600 linii kodu w moim viewmodel i wciąż dużo do dodania).

Szukałem wokół artykułów o tym, jak podzielić/zaprojektować swój pogląd na mniejsze części, ale nie znaleziono satysfakcjonującego rozwiązania. Jedna osoba zasugerowała używanie potomnych modeli widoku, ale prezentowała inne problemy (zależność między modelami widokowymi).

Myślałem o użyciu formantów użytkownika, ale nic nie stoi na poglądzie, że używam na innych widokach tak to niby celowość kontroli użytkowników.

Jakie jest prawidłowe podejście w tej sytuacji?

Dzięki Adrian

Answer 1

Jeśli chcesz podzielić się widok na części składowe, to trzeba zrobić widok kompozycję. Jeśli budujesz aplikację MVVM, to you should really be using an MVVM framework. Coś takiego jak Caliburn.Micro sprawia, że ​​widok jest niesamowicie łatwy.

Tam nie musi być koniecznie Zależności między widokiem modeli, powinni wiedzieć, tylko o to, czego potrzebują, w celu wytworzenia ich pogląd. Może to być podzbiór obiektu biznesowego, który zawiera macierzysty model widoku. Ponieważ model widoku nadrzędnego będzie miał odwołania do wszystkich modeli widoku podrzędnego, może przekazywać im odpowiednie części obiektu biznesowego w punkcie ich budowy.

Answer 2

Zgadzam się również z tym, że Caliburn.Micro jest dobrym rozwiązaniem do dzielenia aplikacji na mniejsze komponenty.

W Caliburn.Micro komunikacja między ViewModels bazuje na wzór Event aggregator.

To sprawia, luźne sprzężenie pomiędzy ViewModels

Answer 3

zgadzam się z użyciem Caliburn Micro.

jednak grać adwokata diabła można podzielić się swoją ViewModel plik w osobnych plikach (sama nazwa klasy) i użyj słowa kluczowego partial przed słowem kluczowym class. Zasadniczo jest ono bardziej stabilne i oddalone o jeden krok (prekursor niełamliwy) od rozbicia na oddzielne klasy.

Answer 4

Dzielenie nie jest idealne.

Wygląda to tak, jakby narzędzi Caliburn skupia się na imprezach, podczas gdy mój wniosek w dużej mierze opiera się na implementacje ICommand.

Dla mnie pierwsze spotkanie z Caliburn.Micro było niezadowalające. Instalacja okazała się być dostosowana do VS2010 - co brzmiało obiecująco - ponieważ mam VS2010 pro. Ale zgubiłem się w konfiguracji Silverlight. W porównaniu do zestawów narzędzi, takich jak Prism, brak mu łatwego startu. Przejście zajmuje teraz dużo czasu. Używam własnego paradygmatu MVVM, jest on mniej abstrakcyjny niż Caliburn, integruje obsługę wielu języków na całym świecie, a po prostu staje w obliczu jednego akceptowalnego problemu niektórych źródeł, które stają się zbyt duże ze względu na naturę paradygmatu Binding/DataContext. Za ten problem uważam, że "częściowa klasa" to rozwiązanie - mimo że wiem, że istnieje bardziej eleganckie rozwiązanie.

W gorączce mojej pracy nie mogę zmienić na inny zestaw narzędzi.

Tak więc delikatnie czekam, aż Microsoft pozwoli na większą elastyczność wokół tego paradygmatu Binding/DataContext.

Może się zdarzyć, że Caliburn pokazuje więcej inteligencji, przydzielając model widoku do jakiejś pozycji. Czy to ? (Myślę, że tak).

Co może być inną opcją jest zdefiniowanie niestandardowego (użytecznego dla Xaml) obiektu, który wyzwala niestandardowy alokator, któremu zostanie przydzielone sterowanie do którego viewmodelu. Co ty na to ?