2009-12-22 6 views
8

Załóżmy, że mam klasę o nazwie Customer. Teraz muszę renderować klienta na widoku. Stworzyłem więc CustomerViewModel do użycia w wiązaniu. Szukam najlepszego sposobu tworzenia klasy CustomerViewModel. Poniżej znajdują się moje przemyślenia na temat jego tworzenia.Najlepszy sposób tworzenia ViewModel w MVVM

1 - Utwórz ponownie wszystkie właściwości w kliencie na modelu widoku. Wstaw instancję klienta do modelu widoku, a każda właściwość zwróci wartość z tego obiektu klienta. Zaletą tej metody jest to, że mogę utworzyć wspólną klasę bazową dla wszystkich modeli widoków i porzucić tam wspólną funkcjonalność. Wadą będzie czas potrzebny do ponownego utworzenia wszystkich właściwości modelu widoku i wykonania konserwacji.

2 - Wyprowadź model widoku od klienta. Tak więc mam wszystkie modele proprech klienta w widoku. Ale to nie pozwoli mi używać wspólnej klasy bazowej i umieszczać tam logikę modelu wspólnego widoku.

Zastanawiam się więc, jaka będzie najlepsza metoda tworzenia modelu widoku? Czy są jakieś alternatywne metody, które są lepsze niż to, co myślałem?

+0

Ile czasu zajmuje powtórzenie właściwości modelu w ViewModel? Umieszczenie w konwerterze lub wyzwalaczu do celów wyświetlania sprawia, że ​​warte są dla mnie dodatkowe minuty. Jeśli masz złożony widok z wieloma kontrolkami, dodaj model jako właściwość w viewmodelu i połącz z Model.Property w widoku. – adrianm

+2

Chciałbym omijać # 2. Nie sądzę, że zawsze znajdziesz wyraźne odwzorowanie między określoną klasą modelu a ViewModel.Dla łatwości obsługi chciałbym przejść z inną klasą, która mogłaby logicznie usiąść przed modelem niestandardowym, ale mogłaby również wystawić inne typy modeli w przyszłości na widok. –

Odpowiedz

5

Powinieneś rozważyć przeczytanie Josh Smith's article na MVVM.

Ma również strukturę o nazwie MVVM Foundation, która ma klasę podstawową ViewModel. Ogólnie myślę, że sposób w jaki implementuje ViewModel jest najlepszy ogólnie.

+0

Widziałem już to. Wykonuje on metodę opisaną w punkcie 1. –

+0

Tak ... Myślę, że to najlepsza metoda. Pracowałem nad jednym projektem z ponad 100 ViewModels i była to najlepsza metoda i najłatwiejsza w utrzymaniu. Mam nadzieję, że pomaga –

0

Jeśli oryginalna klasa klienta nie obsługuje powiązania danych, konieczne będzie utworzenie klasy viewmodel i skopiowanie właściwości klasy klienta.

Jeśli jednak Twoja klasa Klienta już implementuje obsługę powiązania danych (ma ona właściwości zależności lub implementuje INotifyPropertyChanged), nie ma żadnego podstawowego powodu, dla którego nie można powiązać bezpośrednio z właściwościami klasy Klient.

Możesz oczywiście mieć inne względy - możesz chcieć, aby twój model wyświetlania wykonywał określone operacje w odpowiedzi na zmiany właściwości lub nie chcesz, aby obiekty Klienta były bezpośrednio modyfikowane. W takim przypadku nadal będziesz chciał owinąć klasę klienta.

Ponadto, możesz chcieć wspierać sprawdzanie poprawności danych za pośrednictwem interfejsu IDataErrorInfo. W takim przypadku, jeśli twoja klasa klienta nie implementuje tego interfejsu, prawdopodobnie będziesz musiał go również zawinąć.

5

Opcja 1 jest znacznie lepsza. Powodem jest to, że chcesz móc zmieniać te dwie warstwy niezależnie. Posiadanie ścisłego sprzężenia między modelem Twojej domeny a modelem podglądu wprowadzi sztywność w procesie rozwoju, którego chcesz uniknąć.

Sposób, w jaki radzę sobie z pisaniem tak dużo kodu, to to, że nie mam. Używam T4 templates, pewnych rozsądnych konwencji (właściwości, domyślnie pojawiają się w modelu widoku, klasy modelu domeny implementują INotifyPropertyChanged i są delegowane w górę), oraz plik konfiguracyjny do obsługi projekcji/spłaszczania i generowania modeli widoku. Generuję je również jako częściowe klasy, aby móc zająć się dodawaniem do nich innych kodów.