Wie kann mein ViewData null sein, aber im Debugger erweiterbar?

Question

Stieß gerade auf einen interessanten Effekt beim Debuggen einer Aussicht. Das Szenario ist leicht zu reproduzieren - ich habe einen Haltepunkt in a View, im Uhrfenster füge ich hinzu ViewBag.ViewData Und der Wert ist null. Wenn ich jedoch nur hinzufüge ViewBag und erweitern das Objekt, ich kann das sehen ViewData Und es ist nicht null. Ich kann es auch erfolgreich erweitern und seine Eigenschaften sehen.

Kann jemand erklären, ob es sich um einen Fehler handelt oder was dieses Verhalten verursacht?

BEARBEITEN

ViewBag.ViewData ist eigentlich null. ZB, wenn ich diesen Code in der Ansicht habe:

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

Es zeigt die Spannweite an. Der seltsame Teil ist also, dass ich es im Uhrfenster erweitern und die Eigenschaften sehen kann.

Edit2

Als Antwort auf die Antwort von @darin dimitrov - ich habe versucht, dieses Verhalten mit einer benutzerdefinierten Testklasse zu reproduzieren, und ich bekomme eine RuntimeBinderException Beim Versuch, auf das Privateigentum zuzugreifen: '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 diesem Fall sollte ich beim Zugriff nicht die gleiche Ausnahme erhalten ViewBag.ViewData in der Ansicht (die Linie mit if (ViewBag.ViewData == null))?

Answer 1

Was Sie im Debugger/Uhrenfenster sehen, ist das Privatgelände ViewData Eigentum des ViewBag. Wenn Sie den Test in der Ansicht durchführen, haben Sie offensichtlich keinen Zugriff auf dieses private Bereich und Sie erhalten Null, da es kein entsprechendes öffentliches Eigentum gibt.

Führen Sie nun den folgenden Test in der Ansicht durch:

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

Und Sie werden die Spannweite nicht sehen.

Natürlich ist das alles sehr lustig, aber wenn es darum geht, reale Welt zu schreiben und ASP.NET -MVC -Anwendungen richtig zu architektieren ViewData und ViewBag keinen Platz haben. Diese beiden sind meine schlimmsten Feinde in der ASP.NET -MVC -Anwendungsentwicklung.

Schlussfolgerung: Verwenden Sie immer Ansichtsmodelle und stark typisierte Ansichten und haben Sie Spaß.

Answer 2

Ich habe keine technische Erklärung, aber ich glaube, das liegt daran, dass ViewBag dynamisch ist. Es ist wie eine Uhr auf einen Ausdruck, Sie sehen den Inhalt des Ergebnissets nicht, ohne den Ausdruck auszuführen.

Ich denke, der Viewbag verhält sich genauso, weil Sie direkt zu einer Eigenschaft gehen, die nicht geladen wurde, und dies über einen Debugger tun, sie beschließt einfach, diese Eigenschaft nicht zu laden.

Ich könnte natürlich völlig falsch sein: D.

Tut es nur aus Argumenten, tut es das gleiche in Schnellwachen oder im unmittelbaren Fenster?

Answer 3

Während Ihr Code immer innerhalb der Grenzen eines bestimmten Umfangs (Klasse, Methode, privat usw.) läuft, hat der Debugger keine solchen Grenzen

Answer 4

Warum verweisen Sie auf viewbag.viewData? Referenz einfach direkt auf ViewData. Dies kann funktionieren, da hinter den Kulissen Viewbag ViewData verwendet, um eine interne Darstellung von ViewData zu betrachten, getrennt als Ihre Dynamimc -Eigenschaft von "viewData".

Nach dem Testen zeigt sich ViewBag als nicht öffentliches Mitglied ... das würde ich erwarten. System.Web.Mvc.dynamicviewDatadictionary hat ein nicht öffentliches Mitglied ViewData