Widoki MVC3: Obsługa modeli zerowych z finezją

Question

Zbyt często natrafiłem na sytuację, w której widok w moim projekcie powoduje zgłoszenie odwołania o wartości zerowej .

@model Johnny.Application.TestModel 
<div>@(Model.SomeText)</div> 

to zgłasza błąd jeśli model jest zerowy.

Ale jak radzą sobie z tym ludzie? Na pewno nie widzę wszędzie przykładów kodu z brzydkimi zerami sprawdzającymi zaśmiecanie kodu w widoku. To prowadzi mnie do przekonania, że ​​przez większość czasu kontrolerzy nie powinni zwracać modeli zerowych. Ale jak możesz wymusić to z większą finezją?

Teraz, gdy ktoś przypadkowo spowoduje, że kontroler zwróci model zerowy, model widoku wysadza się i wygląda na wadliwy. W rzeczywistości była to wina kontrolera. A widok może nawet nie "złapać" problemu, zrobi to tylko wtedy, gdy członkowie modelu zdążą się przyzwyczaić (co jest oczywiście w większości przypadków).

Z różnych powodów niektóre widoki mogą obsługiwać wartości puste. Nie spodziewałbym się, że będzie to jednak przypadek większości. Najwyraźniej chodzi o ustalenie jakiejś "umowy" między widokiem a kontrolerem.

Nie lubię opcje Widziałem:

1. Sprawdź, czy model jest zerowa za każdym razem jest on wykorzystywany. Bardzo lame!
2. Jedno z nich: duże, jeśli instrukcja zawija cały widok za pomocą zerowego modelu sprawdzania. Pomyśl o zmarnowanym kodzie nieruchomości. Kulawy!
3. Dodaj numer , jeśli sprawdzisz rzutem u góry. Nieźle, ale wydaje się głupie. Lekko kulawy.

chciałbym wiedzieć, czy coś takiego istniało tych opcji, aby ustawić „null” nie zamówienia:

• atrybut na metodzie kontrolera jak [NoNullModels]. Wątpię, aby tak się stało, ponieważ nie sądzę, aby kontroler wiedział, do czego jest podłączony.
• W widoku, wskaźnik jak @ MVC3.HeyDontAllowNulls lub inny standardowy sposób rzuca wyjątek (jak opcja 3 powyżej)

Answer 1

zadałem podobne pytanie tutaj Should one try to guard against null reference exceptions/index out of bounds exceptions in MVC views? i dostał dobre odpowiedzi do niego. W skrócie, preferowane jest dodawanie kontroli null w kontrolerach, a nawet w jednostkowych testach zamiast w widokach.

Answer 2

Istnieje wiele preferencje tutaj, niektórzy, że można zrobić to:

1. Rzut RecordNotFoundException w warstwie danych (niestandardowych wyjątku) i mają globalny połowów przy filtra wyjątek ten
2. Sprawdzić null wracających z repozytorium i uchwyt w scenariuszu indywidualnego przypadku:
3. Udekoruj swoje kontrolery, aby szukały modelu zerowego w metodach GET, które nie są metodami CREATE (lub regułami, które uznasz za w porządku) za pomocą atrybutu filtru akcji, aby sprawdzić to w programie OnActionExecuted

Nawet moje widoki "CREATE" na ogół otrzymują model, nawet jeśli są puste (choć często mają w nich IEnumerable <SelectListItem>), więc powinny zawsze mieć model idący do nich.

Answer 3

Sprawdzam wartości null w moich widokach, czasami w częściach, które tego wymagają.

Będę też czasami tworzył wartości domyślne w moim kontrolerze, jeśli ma być wartość pusta, zależy od tego, co próbujesz zrobić i co jest do przyjęcia.

Mam na przykład przypadek, w którym ludzie subskrybują coś i ustawiają powiadomienia. Jeśli nie mają powiadomień, sub-obiekt mojego modelu ma wartość zerową. Nie chcę ustawiać wartości domyślnych, więc mam tam czek. W innych sekcjach po prostu używam wartości domyślnej.