Modelbinding para los parámetros de cadena de consulta vacíos en ASP.NET MVC 2

Question

describe aquí parece ser ahora la predeterminado para ASP.NET MVC 2 (al menos para la vista previa 1).

Cuando modelbinding una cadena de consulta como esta:

 ?Foo=&Bar=cat 

se produce la siguiente unión (suponiendo que estés unión a un modelo con 'Foo' y 'Bar' propiedades de cadena)

ASP.NET MVC 1

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

ASP.NET MVC 2 (vista previa 1 a través de RC)

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

Se busca dar a cualquier persona que está jugando con una mano a mano V2 ya que esto no se menciona en el ' gu-notas '. También curiosidad por si alguien en el saber puede hacer comentarios sobre si es o no será la aplicación final o una característica configurable? Estoy bien de cualquier manera, pero sólo espero que ellos no cambie de nuevo a la vieja manera! Siendo configurable sería aún mejor.

Editar La lección que aprender de este punto es cualquier versión está desarrollando en contra de no escribir código que dice Foo.Length == 0 a prueba para una cadena vacía o Foo.Length> 3 para comprobar si hay una longitud mínima. Utilice String.IsNullOrEmpty (Foo) y / o detectar la presencia nula en primer lugar.

---

Actualización: Esta pregunta despertó mi curiosidad acerca de por qué iban a hacer realidad este cambio. Creo que me encontré con la respuesta mientras que la investigación controles deshabilitados. La especificación W3 HTML define un 'control exitoso ' como sigue:

  

Un control exitoso es "válido" para   sumisión. Cada control exitoso   tiene su nombre de control emparejado con su   valor actual como parte de la presentada   conjunto de datos de formulario. Un control exitoso   deberá definirse dentro de un elemento de formulario   y debe tener un nombre de control.

En otras palabras - un control exitoso es aquel que lo hará de nuevo al servidor como un parámetro de cadena de consulta. Ahora, si un control no tiene un valor válido entonces, de acuerdo a la especificación:

  

Si un control no tiene un valor actual   cuando se envía el formulario, el usuario   Los agentes no están obligados a tratarlo como   un control exitoso.

(detectar el idioma 'abierto a la interpretación' aquí con 'no se requiere que ...')

Así que creo enviando un nulo en lugar de una cadena vacía reduce incompatibilidades del navegador, donde algunos navegadores pueden enviar Foo=&Bar= y otros ni siquiera pueden enviar ese parámetro de cadena de consulta. Por siempre interpretar Foo= como si Foo no estaba allí en todas las fuerzas a ser más defensivo.

Creo que estoy al menos en el camino correcto en cuanto a la razón por la cual aquí - y por lo menos en parte, tiene algo que ver con la noción de un 'control succcessful'.

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

Answer 1

NULL es más representativo de lo que realmente es, y es compatible con otros tipos anulables además de cuerda, así que me imagino que es por diseño.

Answer 2

Yo prefiero el comportamiento de v1. ¿Cómo va a ser capaz de pasar una cadena vacía en v2? Además, con este último no se puede saber si foo es en los parámetros de consulta o no.

Answer 3

Una forma de configurar sería sustituir el ligante modelo por defecto en V2 (o V1) para obtener un comportamiento coherente. Yo prefiero la hipótesis nula, a mí mismo.