tutorial - Modelbinding para parámetros de cadena de consulta vacíos en ASP.NET MVC 2
net core search (3)
El comportamiento descrito aquí parece ser ahora el predeterminado para ASP.NET MVC 2 (al menos para la Vista previa 1).
Al enlazar un modelo a una cadena de consulta como esta:
?Foo=&Bar=cat
Se produce el siguiente enlace (asumiendo que estás vinculando a un modelo con propiedades de cadena ''Foo'' y ''Bar'')
ASP.NET MVC 1
model.Foo = "";
model.Bar = "cat":
ASP.NET MVC 2 (vista previa 1 a RC)
model.Foo = null;
model.Bar = "cat":
Quería darle un aviso a cualquiera que esté jugando con V2 ya que esto no se mencionó en las '' gu-notes ''. ¿También es curioso si alguien que sabe puede comentar si esta será o no la implementación final o una característica configurable? Estoy bien de cualquier manera, ¡pero espero que no vuelvan a la forma antigua! Ser configurable sería aún mejor.
Edición: la lección que aprenderá de este punto es cualquier versión que esté desarrollando en contra de no escribir código que diga Foo.Length == 0 para probar una cadena vacía o Foo.Length> 3 para verificar una longitud mínima. Use string.IsNullOrEmpty (Foo) y / o busque primero el valor nulo.
Actualización: esta pregunta despertó mi curiosidad acerca de por qué harían este cambio. Creo que me topé con la respuesta al investigar los controles con discapacidad. La especificación HTML de W3 define un '' control exitoso '' de la siguiente manera:
Un control exitoso es "válido" para el envío. Cada control exitoso tiene su nombre de control emparejado con su valor actual como parte del conjunto de datos del formulario enviado. Un control exitoso debe definirse dentro de un elemento FORM y debe tener un nombre de control.
En otras palabras, un control exitoso es aquel que regresará al servidor como un parámetro de cadena de consulta. Ahora, si un control no tiene un valor válido, entonces de acuerdo con la especificación:
Si un control no tiene un valor actual cuando se envía el formulario, los agentes de usuario no están obligados a tratarlo como un control exitoso.
(Localice el lenguaje ''abierto a la interpretación'' aquí con ''no es obligatorio para ...'')
Así que creo que al enviar un nulo en lugar de una cadena vacía, se reducen las incompatibilidades del navegador donde ciertos navegadores pueden enviar Foo=&Bar= y otros incluso no pueden enviar ese parámetro de cadena de consulta. Al interpretar siempre a Foo= como si Foo no estuviera allí, te obliga a estar más a la defensiva.
Creo que al menos estoy en el camino correcto en cuanto a la razón por la cual aquí, y al menos en parte tiene algo que ver con la noción de un "control exitoso".
Null es más representativo de lo que realmente es, y es compatible con otros tipos anulables además de string, así que me imagino que es por diseño.
Prefiero el comportamiento de v1. ¿Cómo podrás pasar una cadena vacía en v2? Además, con este último no se puede saber si foo está en los parámetros de consulta o no.
Una forma de configurar sería reemplazar el cuaderno de modelos predeterminado en V2 (o V1) para obtener un comportamiento consistente. Yo prefiero el nulo, yo mismo.