Czy istnieje lepszy sposób niż używanie klas statycznych lub pojedynczych dla MVVM?

Question

Odkryłam, że w wielu przypadkach, wydaje się (przynajmniej pozornie) do sensu używać pojedynczych lub klas statycznych modeli w mojej aplikacji WPF MVVM. Głównie dlatego, że większość moich modeli musi być dostępna w całej aplikacji. Tworzenie modeli static pozwala w prosty sposób spełnić to wymaganie.

A jednak, jestem konflikt, bo wszyscy na planecie wydaje się nienawidzić pojedynczych. Więc zastanawiam się, czy nie jest lepszy sposób, czy też robię coś oczywiście nie tak?

Answer 1

Istnieje kilka problemów z pojedynczych. Opiszę je poniżej, a następnie zaproponuję alternatywne rozwiązania. Nie jestem "Nigdy nie używaj singletona, albo jesteś typem kolesia", jak sądzę, że mają swoje zastosowania. Ale te zastosowania są rzadkie.

1. Bezpieczeństwo nici. Jeśli masz globalny statyczny Singleton, to musi być bezpieczny dla wątków, ponieważ wszystko może uzyskać do niego dostęp w dowolnym momencie. To dodatkowy koszt.

2. Testowanie jednostek jest trudniejsze w przypadku Singletonów.

3. Jest to tani zamiennik zmiennych globalnych (to znaczy, że jest to singleton na koniec dnia, chociaż może mieć metody i inne wymyślne rzeczy).

See, to nie tak, że Singleton to „obrzydliwe obrzydliwości” per-se, ale że jest to pierwszy wzorzec projektowy wielu nowych programistów dostać do czynienia i jego wygoda zaciemnia jego pułapek (Wystarczy trzymać jakieś biegi na to i nazwijcie to parowym punkiem).

W twoim przypadku odnosisz się do modeli i zawsze są to "instancje", ponieważ w naturalny sposób odzwierciedlają dane. Być może martwisz się kosztem uzyskania tych instancji. Uwierzcie mi, że powinny być pomijalne (oczywiście w odniesieniu do projektowania dostępu do danych).

więc alternatywy? Przekaż model do miejsc, które tego wymagają. To sprawia, że ​​testowanie jednostek jest łatwiejsze i pozwala wymieniać podstawy tego modelu w rytmie serca. Oznacza to również, że możesz chcieć spojrzeć na interfejsy - oznaczają one kontrakt. Możesz wtedy tworzyć konkretne obiekty, które implementują te interfejsy i voila - Twój kod jest łatwy do testowania jednostkowego i modyfikowalny.

W świecie singleton, pojedyncza zmiana na singleton może całkowicie złamać wszystko w bazie kodu. To nie jest dobra rzecz.

Answer 2

myślę przyjętego rozwiązania tego problemu jest użycie Dependency Injection. Dzięki wtryskowi zależności możesz zdefiniować swoje modele jako regularne, niestatyczne klasy, a następnie mieć odwrócenie kontenera kontrolnego "wstrzyknąć" instancję modelu, kiedy chcesz.

Jest miły w wpftutorial.net poradnik, który pokazuje jak zrobić zastrzyk w zależności WPF: http://wpftutorial.net/ReferenceArchitecture.html

Answer 3

Jedyna klasa statyczna, której używam, to MessageBroker, ponieważ potrzebuję tej samej instancji w całej aplikacji.

Ale nawet wtedy bardzo możliwe jest użycie Unity (lub innego Injection Injection/Container) do zarządzania instancjami zajęć, których potrzebujesz tylko jeden.

Pozwala to wprowadzić różne wersje w razie potrzeby (nppodczas testów jednostkowych)

Przy okazji: Statyczny to nie to samo co singleton. Ale nie robię tego tutaj. Wystarczy przeszukać stackoverflow, aby uzyskać więcej ciekawych pytań na ten temat: