13

que tiene una acción de controlador cuya definición se ve como-defecto Modelo Carpeta no se une a los tipos anulables en IEnumerable

public ActionResult ChangeModel(IEnumerable<MyModel> info, long? destinationId) 

Y el modelo:

public class MyModel 
{ 
    public string Name; //Gets populated by default binder 
    public long? SourceId; //remains null though the value is set when invoked 
} 

El 'Nombre' propiedad obtiene poblado en la acción del controlador, sin embargo, la propiedad SourceId sigue siendo nula. El destinationId que es un de largo? El parámetro se llena también.

Al pasar por el código fuente de MVC (versión 2) esta es la excepción lanzada por DefaultModelBinder.

La conversión de parámetros de tipo 'System.Int32' para escribir 'System.Nullable`1 [[System.Int64, mscorlib, versión = 2.0.0.0, Culture = neutral, PublicKeyToken = b77a5c561934e089]]' falló porque ningún convertidor de tipo puede convertir entre estos tipos.

Si el modelo cambia a largo en lugar de largo ?, el encuadernador de modelo predeterminado establece el valor.

public class MyModel 
{ 
    public string Name {get;set;}; //Gets populated by default binder 
    public long SourceId {get;set;}; //No longer long?, so value gets set 
} 

¿Es esto un problema conocido? Como el código fuente de MVC está optimizado, no puedo pasar por la mayoría del código.

Actualización: La solicitud se envía es un HTTP POST usando JSON con la fuente JSON se asemeja -

{"info":[{"Name":"CL1","SourceId":2}], "destinationId":"1"} 

Respuesta

1

El defecto Modelo Carpeta está analizando todos los SourceId como valores enteros. Pero parece que a .NET le falta un convertidor de tipo predeterminado de int a long?.

Lo que haría es implementing a type converter para ese caso.

+0

No estoy seguro de si el convertidor de tipos debe ser puesto en, como el otro parámetro de entrada en la acción es largo? (destinationId) y que parece estar poblando bien. – QED

+0

@QED: Sí, soy consciente de eso: el problema parece ser específico del enlace 'IEnumerable <>'. Aún así, eso es lo que probaría; Supongo que el archivador de modelos predeterminado hace explícitamente todas las conversiones entre los tipos integrales simples y sus homólogos anulables, pero no lo hace correctamente para las colecciones.Y sí, eso significa que otra posible solución sería anular la carpeta de modelo predeterminada ... – rsenna

2

yo le recomendaría utilizar propiedades en lugar de campos del modelo de vista:

public class MyModel 
{ 
    public string Name { get; set; } 
    public long? SourceId { get; set; } 
} 

Ahora la petición siguiente:

/somecontroller/changemodel?destinationId=123&info[0].Name=name1&info[0].SourceId=1&info[1].Name=name2&info[1].SourceId=2 

rellena el modelo fino.

+0

Eran originalmente propiedades en el modelo de vista. He actualizado el código y tenga en cuenta que estoy haciendo una publicación con JSon. – QED

+0

@QED, de manera predeterminada, no hay ningún proveedor Json para las solicitudes en ASP.NET MVC 2. Está incorporado ASP.NET MVC 3. Entonces, ¿qué está utilizando para analizar la solicitud JSON en su modelo? –

+0

Estoy haciendo uso de JsonValueProviderFactory disponible en MVCFutures. Los valores parecen ser correctos de-serializados y también se configuran en la tienda de respaldo. – QED

4

Quizás es demasiado tarde, pero encontré una solución. Puede convertir el campo SourceId en cadena antes de enviar datos. Por lo que sus datos JSON se verá como

{"info":[{"Name":"CL1","SourceId":"2"}], "destinationId":"1"}

Esto funcionó en mi situación (Int32 -> decimal ?, ASP .NET MVC 3)

+4

Nunca es tarde, hombre. Gracias por la propina - funcionó para mí. –

Cuestiones relacionadas