MVVM i unikanie monolitycznego obiektu Boga

Question

Jestem w fazie zakończenia dużego projektu, który ma kilka dużych komponentów: pozyskiwanie obrazu, przetwarzanie obrazu, przechowywanie danych, fabryczne operacje wejścia/wyjścia (projekt automatyzacji) i kilka innych.

Każdy z tych komponentów jest rozsądnie niezależny, ale aby projekt działał jako całość, potrzebuję co najmniej jednego wystąpienia każdego komponentu. Każdy komponent ma również ViewModel i View (WPF) do monitorowania stanu i zmiany rzeczy.

Moje pytanie jest najbezpieczniejszą, najbardziej wydajną i najbardziej konserwatywną metodą tworzenia wszystkich tych obiektów, subskrybowania jednej klasy do wydarzenia w innym, oraz posiadania wspólnego ViewModel i widoku dla wszystkich tego.

Czy byłoby najlepiej, gdybym miał klasę nazywaną Bogiem, która ma prywatną instancję wszystkich tych obiektów? Robiłem to w przeszłości i żałowałem tego.

A może byłoby lepiej, gdyby Bóg polegał na instancjach Singleton tych obiektów, aby uzyskać przewracanie piłki.

Alternatywnie, powinien Program.cs (lub gdziekolwiek jest Główny (...)) utworzyć wszystkie te elementy i przekazać je do Boga jako parametry, a następnie niech (snicker) i jego ViewModel radzą sobie z konkretami biegania te projekty.

Wszelkie inne sugestie, które chciałbym usłyszeć.

Dziękujemy!

Answer 1

Mój preferowany sposób uzyskiwania ViewModels używa ViewModelLocater. Zasadniczo jest to obiekt Boga, jak sugerujesz, ale to tylko odpowiedzialność jest stworzenie każdego ViewModel i zachować odniesienia do niego. Zazwyczaj dodajemy VML do zasobów aplikacji i każdy widok jest odpowiedzialny za ustawienie DataContext na odpowiednim ViewModelu. Jeśli subskrybujesz wiele zdarzeń, możesz albo połączyć je ręcznie, albo utworzyć maszynę wirtualną, która najpierw zgłasza zdarzenia i przekazuje ją do zależnej maszyny wirtualnej w jej konstruktorze.

Answer 2

Mam nadzieję, że dobrze zrozumiałem twoje pytanie. Myślę, że używanie God ViewModel nie jest dobrym pomysłem. lepiej jest mieć pojedynczy model widoku dla każdego ze swoich widoków i tworzyć instancje wszystkich powiązanych modeli widoku w tym widoku. następnie możesz użyć mediatora, aby bezpiecznie wysłać wiadomość między modelami widoku tego widoku i innych widoków. również proponuję użyć komend wpf zamiast zdarzeń. można znaleźć artykuł na temat mediatora w here.

Answer 3

Obawy te są pod opieką bardzo ładnie przy użyciu Microsoft "Biblioteka Composite Application" (aka Prism) ramy dla rozwoju złożonych aplikacji WPF:

http://msdn.microsoft.com/en-us/library/ff647752.aspx

http://msdn.microsoft.com/en-us/library/ff648611.aspx

• Komponowanie twoje poglądy: Prism ma koncepcję okna powłoki aplikacji i menedżera regionu. Powłoka działa jako strona z odsłoniętymi krawędziami, w której definiowane są nazwane regiony przypisane do obszaru nazw, np. "MainMenu" i "TabInterface". Zawijacie odniesienia do swoich widoków i modeli widoków w klasach modułów, np. "MainMenuModule" i "TabInterfaceModule" i określ region, z którym moduł ma zostać powiązany. Pryzmat utworzy twoje widoki i wstrzyknie je do regionów powłoki po uruchomieniu aplikacji. Dzięki temu możesz tworzyć własne widoki niezależnie od siebie.

• Komunikacja między viewmodels: Prism obsługuje wzorzec mediatora o nazwie "Agregator zdarzeń". Zasadniczo możesz publikować i subskrybować wiadomości za pośrednictwem agregatora zdarzeń ze swoich viewmodels. Dzięki temu viewmodels mogą swobodnie komunikować się za pośrednictwem wiadomości, a nie muszą wiedzieć o sobie nawzajem i przechwytywać zdarzenia.

Pryzmat popiera i wspiera wzorce do rozwijania elementów niezależnie od siebie w luźny sposób, bez wprowadzania obiektów Boga i łączenia. Dużą częścią Pryzmatu jest także użycie IOC i zastrzyk zależności, więc testowanie jednostkowe staje się znacznie łatwiejsze.

znalazłem następujący artykuł dobrą praktyczne wprowadzenie do korzystania Prism i MVVM:

http://www.developmentalmadness.com/archive/2009/10/03/mvvm-with-prism-101-ndash-part-1-the-bootstrapper.aspx

Answer 4

Spójrz na pewnych ram iniekcji zależność takich jak Jedności (który używa CAL), Zamek Windsor lub wiosną. NETTO.

Answer 5

Możesz użyć kontrolerów(ApplicationController, Use-Case Controller) zamiast klasy "God". Kontrolery są odpowiedzialne za tworzenie obiektów ViewModel i pośredniczą między nimi.

Sposób działania tej funkcji jest sygnalizowany przez projekt WPF Application Framework (WAF).