Kiedy należy używać ViewData zamiast ViewModels?

Question

Zakładając, że chcesz rozwinąć swoje kontrolery, aby użyć ViewModel do przechowywania danych dla renderowanych widoków, czy dane powinny być zawarte w ViewModel? Jakie warunki można obejść, aby obejść ViewModel?

Powód, dla którego pytam, jest w sytuacji, gdy niektóre z kodu używają ViewData, a niektóre używają ViewModel. Chcę rozpowszechniać zestaw wytycznych w zespole, kiedy jest to właściwe, aby korzystać z ViewData, i kiedy jest to po prostu na skróty. Chciałbym uzyskać opinie od innych programistów, którzy zajmowali się tym, aby wiedzieć, że moje wskazówki nie są tylko stronnicze.

Answer 1

Po prostu do dalszych komentarzy Fabiana; możesz wyraźnie upewnić się, że dane widoku nigdy nie są używane, wykonując kroki opisane w this article. Naprawdę nie ma wymówki ani używać modeli do wszystkiego.

Jeśli nie masz innego wyjścia, jak użyć ViewData (powiedz na istniejącym projekcie); przynajmniej użyj stałych łańcuchowych, aby rozwiązać nazwy, aby uniknąć używania "magicznych ciągów znaków". Coś w rodzaju: ViewData[ViewDataKeys.MyKey] = myvalue; Infact, używam tego dla prawie wszystkiego, co musi być "oparte na ciągach znaków" (klucze sesji, klucze pamięci podręcznej, klucze wyjściowe cache VaryByCustom itp.).

Answer 2

Osobiście nigdy nie używam ViewData, wszystko przechodzi przez model, z wyjątkiem sytuacji, gdy testuję coś i szybko muszę widzieć wartość w widoku. Mocne!

Answer 3

Pod względem ASP.NET MVC 2 preferowany jest wzorzec ViewModel. Podejście to w pełni wykorzystuje sprawdzanie statyczne typu kompilacji. To w połączeniu z compiling mvc views spowoduje, że twój przepływ pracy programistycznej będzie znacznie szybszy i bardziej produktywny, ponieważ błędy zostaną wykryte podczas kompilacji/kompilacji w przeciwieństwie do czasu pracy.

Answer 4

Jednym podejściem, które możesz chcieć rozważyć, ponieważ twoje poglądy stają się bardziej złożone, jest zarezerwowanie użycia modeli dla pól wejściowych i użycie ViewData do obsługi czegokolwiek innego, co widok musi renderować.

Istnieje co najmniej kilka argumentów na poparcie tego:

1. Masz master-stronę, która wymaga pewnych danych, aby być obecne (na przykład coś jak StackOverflow informacji użytkownika w nagłówku). Zastosowanie akcji ActionFilter dla całej witryny ułatwia wypełnianie tych informacji w ViewData po każdej akcji. Umieszczenie go w modelu wymagałoby, aby każdy inny Model na stronie dziedziczył z Modelu podstawowego (początkowo może się to wydawać złe, ale może się szybko skomplikować).

2. Podczas sprawdzania poprawności opublikowanego formularza, jeśli występują błędy sprawdzania poprawności, prawdopodobnie będziesz chciał ponownie powiązać model (z nieprawidłowymi polami) z powrotem do widoku i wyświetlić komunikaty sprawdzania poprawności. Jest to w porządku, ponieważ dane w polach wejściowych są odsyłane z powrotem i będą powiązane z modelem, ale co z innymi danymi wymaganymi do ponownego wypełnienia? (np. wartości list rozwijanych, komunikatów informacyjnych itp.) Nie będą one odsyłane z powrotem i może stać się nieprzyjemne ponowne ich zapełnienie na modelu "wokół" wartości wejściowych odłożonych wartości. Często łatwiej jest mieć metodę, która zapełnia dane ViewData danymi typu ..view.

Z mojego doświadczenia wynika, że ​​to podejście działa dobrze.

I w MVC3, dynamic ViewModels oznacza brak indeksowania ciągów!