Come può il mio Viewdata essere nullo, ma espandibile nel debugger?

Question

Proprio imbattuto in un interessante effetto durante il debug di vista. Lo scenario è facile da riprodurre - Ho un punto di interruzione in un View, nella finestra di controllo aggiungo ViewBag.ViewData e il valore è null. Tuttavia, se ho appena aggiungo ViewBag ed espandere l'oggetto, posso vedere il ViewData e non è null. Posso anche con successo espanderla e vedere le sue proprietà.

Qualcuno può spiegare che si tratti di un bug o che cosa provoca questo comportamento?

Modifica

ViewBag.ViewData è in realtà null. Per esempio. se ho questo codice nella vista:

if (ViewBag.ViewData == null)
{
    <span>ViewBag.ViewData is null</span>
}

visualizza la durata. Quindi la parte strana è che posso espanderlo nella finestra di controllo e vedere le proprietà.

EDIT2

In risposta alla risposta di @Darin Dimitrov - ho cercato di riprodurre questo comportamento con una classe di test personalizzati e ottenere un RuntimeBinderException quando si tenta di accedere alla proprietà privata: 'SomeClass.SomeProperty' is inaccessible due to its protection level:

public class SomeClass
{
    private string SomeProperty;
}

dynamic dynamicObject = new SomeClass();
if (dynamicObject.SomeProperty == null)
{
    Console.WriteLine("dynamicObject.SomeProperty is null");
}

In questo caso, non dovrei essere sempre la stessa eccezione quando si accede ViewBag.ViewData nella vista (la linea con if (ViewBag.ViewData == null))?

Answer 1

Quello che si vede nella finestra del debugger / orologio è il privati ?? di proprietà ViewData del ViewBag. Quando si esegue il test della vista che si ha, ovviamente, non ha accesso a questo campo privato e si ottiene nulla, perché non esiste una proprietà pubblica corrispondente.

Ora fare il seguente test nella vista:

@if (null == ViewBag
         .GetType()
         .GetProperty("ViewData", BindingFlags.Instance | BindingFlags.NonPublic)
         .GetValue(ViewBag, null)
)
{
    <span>ViewBag.ViewData is null</span>
}

e non sarà possibile vedere l'arco.

Naturalmente tutto questo è molto divertente, ma quando si tratta di scrivere mondo reale e correttamente architettati applicazioni ASP.NET MVC, sia ViewData e ViewBag non hanno posto. Quei due sono miei peggiori nemici nello sviluppo di applicazioni ASP.NET MVC.

Conclusione:. Utilizzare sempre modelli vista e punti di vista fortemente tipizzati e divertirsi

Answer 2

Non ho una spiegazione tecnica, ma credo che sia perché ViewBag è dinamico. E 'come fare un orologio su un'espressione, non si vede il contenuto del gruppo di risultati senza correre l'espressione.

Credo che la ViewBag si comporta nello stesso modo, perché si sta andando direttamente a una proprietà che non è stato caricato, e si sta facendo attraverso un debugger, decide semplicemente di non caricare la proprietà.

I potrebbe essere del tutto sbagliato, ovviamente: D

Solo per amor di argomenti, fa fare lo stesso in rapido orologio o la finestra immediata?

Answer 3

Mentre il codice viene eseguito sempre nei limiti di certo ambito (classe, metodo, privati, ecc), il debugger non ha tali limiti

Answer 4

perché ti fa riferimento ViewBag.ViewData? Basta fare riferimento direttamente Viewdata. Questo può funzionare perché dietro le quinte usi viewbag viewdata si può essere alla ricerca di una rappresentazione interna di Viewdata, separare quanto la vostra proprietà dynamimc di "Viewdata"

Dopo aver testato questo fuori, spettacoli ViewBag come membro non pubbliche ... che è quello che mi aspetterei. System.Web.Mvc.DynamicViewDataDictionary ha un membro non pubblico Viewdata