Modelbinding per vuoto parametri di stringa di query in ASP.NET MVC 2
-
13-09-2019 - |
Domanda
descritto qui sembra essere ora il predefinito per ASP.NET MVC 2 (almeno per Preview 1).
Quando modelbinding una querystring in questo modo:
?Foo=&Bar=cat
si verifica la seguente vincolante (supponendo che si sta legandosi a un modello con 'Foo' e 'Bar' proprietà di stringa)
ASP.NET MVC 1
model.Foo = "";
model.Bar = "cat":
ASP.NET MVC 2 (anteprima da 1 a RC)
model.Foo = null;
model.Bar = "cat":
Ha voluto dare a nessuno che sta giocando con V2 un testa a testa dal momento che questo non è stato menzionato in ' gu-note '. Anche curioso di sapere se qualcuno è a conoscenza può commentare o meno questo sarà l'attuazione definitiva o di una funzione configurabile? Io sto bene in entrambi i casi, ma solo che essi non tornare alla vecchia maniera! Essere configurabile sarebbe ancora meglio.
Modifica La lezione da imparare da questo punto è qualsiasi versione si sta sviluppando contro non scrivere codice che dice Foo.Length == 0 a prova per una stringa vuota o Foo.Length> 3 per verificare per un periodo minimo. Utilizzare string.IsNullOrEmpty (Foo) e / o verifica per prima nullo.
Aggiornamento: Questa domanda ha suscitato la mia curiosità sul perché sarebbe in realtà fare questo cambiamento. Penso che mi sono imbattuto sulla risposta durante la ricerca dei controlli disabili. Le specifiche W3 HTML definisce un ' controllo di successo ' come segue:
Un controllo di successo è "valido" per presentazione. Ogni controllo di successo ha il nome di controllo accoppiato con il suo valore corrente come parte del presentato set dati del modulo. Un controllo di successo deve essere definita in un elemento FORM e deve avere un nome di controllo.
In altre parole - un controllo di successo è quella che lo renderà di nuovo al server come un parametro di stringa di query. Ora, se un controllo non ha un valore valido poi in base alle specifiche:
Se un controllo non ha un valore corrente quando il modulo viene inviato, utente agenti non sono tenuti a trattare come un controllo di successo.
(individuare il 'aperto all'interpretazione' linguaggio qui con 'non richiesto a ...')
Quindi penso con l'invio di un null al posto di una stringa vuota riduce incompatibilità del browser in cui alcuni browser possono inviare Foo=&Bar=
e gli altri non possono anche inviare quel parametro stringa di query. Interpretando sempre Foo=
come se Foo non era lì a tutte le forze di essere più difensivo.
Credo di essere, almeno sulla strada giusta per quanto riguarda il motivo per cui qui - e almeno in parte ha a che fare con la nozione di un 'controllo di succcessful'.
Soluzione
nulla è più rappresentativo di ciò che effettivamente è, ed è compatibile con altri tipi nullable oltre a stringa, quindi immagino che sia di progettazione.
Altri suggerimenti
Io preferisco il comportamento di v1. Come si sarà in grado di passare una stringa vuota in v2? Inoltre, con questi ultimi non si può dire se foo è nei parametri di query oppure no.
Un modo per configurare sarebbe quello di sostituire il legante modello predefinito in V2 (o V1) per ottenere un comportamento coerente. Io preferisco il nulla, io.