Modelbinding für leere Abfragezeichenfolgenparameter in ASP.NET MVC 2

Question

Das Verhalten described here scheint jetzt der Standardwert für ASP.NET MVC 2 (mindestens für Vorschau 1).

Wenn ein Abfragezeichenfolgeflag wie diese modelbinding:

?Foo=&Bar=cat 

Die folgende Bindung erfolgt (vorausgesetzt, Sie zu einem Modell mit 'Foo' sind verbindlich und 'Bar' string Eigenschaften)

ASP.NET MVC 1

model.Foo = ""; 
model.Bar = "cat": 

ASP.NET MVC 2 (Vorschau 1 bis RC)

model.Foo = null; 
model.Bar = "cat": 

Wollte jemand geben, die mit V2, da dies in der ‚gu-notes‘ nicht erwähnt wurde ein Heads-up gespielt wird. Auch neugierig, ob jemand, der Bescheid weiß, kommentieren kann, ob dies die endgültige Implementierung oder ein konfigurierbares Feature sein wird? Mir geht es in jeder Hinsicht gut, aber ich hoffe nur, dass sie nicht auf den alten Weg zurückgehen! Konfigurierbar wäre noch besser.

Edit: Die Lehre aus diesem Punkt zu lernen, ist, was Version Sie entwickeln gegen nicht Code zu schreiben, sagt Foo.Length == 0 für eine leere Zeichenfolge zu testen oder Foo.Length> 3 zu prüfen eine minimale Länge. Verwenden Sie string.IsNullOrEmpty (Foo) und/oder prüfen Sie zuerst auf Null.

---

Update: Diese Frage löste meine Neugier, warum würden sie tatsächlich diese Änderung vornehmen. Ich denke, dass ich bei der Untersuchung von Behinderungskontrollen auf die Antwort gestoßen bin. Die W3 HTML-Spezifikation definiert eine ‚successful control‘ wie folgt:

Eine erfolgreiche Steuerung „gültig“ für Vorlage ist. Bei jedem erfolgreichen Steuerelement ist der Steuerelementname mit dem aktuellen Wert als Teil des übermittelten Formulardatensatzes gepaart. Ein erfolgreiches Steuerelement muss in einem FORM-Element definiert werden und muss einen Steuerelementnamen haben.

Mit anderen Worten - ein erfolgreiches Steuerelement ist eines, das es als Abfragezeichenfolgenparameter zurück zum Server macht. Nun, wenn eine Kontrolle keinen gültigen Wert dann entsprechend der Spezifikation:

Wenn ein Steuerelement nicht über ein current value wenn das Formular abgeschickt wird, Benutzer Mittel sind nicht zu behandeln es erforderlich, als eine erfolgreiche Kontrolle.

(vor Ort die ‚offen für Interpretation‘ Sprache hier mit ‚nicht erforderlich ...‘)

Ich denke also, durch eine Null statt einer leeren Zeichenfolge sendet es Browser Inkompatibilitäten reduziert, wo bestimmte Browser kann senden Sie Foo=&Bar= und andere möglicherweise nicht einmal diesen Abfragezeichenfolgenparameter senden. Indem du immer Foo= interpretierst, als ob Foo überhaupt nicht da wäre, zwingst du dazu, defensiver zu sein.

Ich denke, ich bin zumindest auf dem richtigen Weg, was den Grund hier angeht - und hat zumindest teilweise etwas mit der Idee einer "erfolgreichen Kontrolle" zu tun.

http://www.w3.org/TR/html401/interact/forms.html#h-17.13.2

Answer 1

Null ist mehr Vertreter dessen, was es eigentlich ist, und es ist kompatibel mit anderen Nullable Types neben string, so stelle ich mir es durch Design ist.

Answer 2

Eine Möglichkeit zum Konfigurieren wäre das Ersetzen des Standardmodellbinders in V2 (oder V1), um konsistentes Verhalten zu erhalten. Ich bevorzuge die Null, ich selbst.

Answer 3

Ich bevorzuge das Verhalten von v1. Wie können Sie in v2 eine leere Zeichenfolge übergeben? Darüber hinaus können Sie mit letzterem nicht sagen, ob foo in den Abfrageparametern ist oder nicht.