asp.net-mvc - university - update model from database entity framework

¿Cuál es el comportamiento correcto de UpdateModel en ASP.NET MVC?

Question

Estoy interesado en saber qué creen ustedes que deberían considerarse como "comportamiento correcto" en términos del método UpdateModel en ASP.NET MVC.

La razón por la que pregunto aquí es tal vez si esta funcionalidad es "por diseño", alguien podría aclarar por qué es así, y tal vez una forma de llamarlo de manera diferente para lograr la funcionalidad deseada, lo cual me imagino que sería la forma en que lo hago. ¿% de la gente querría que esto funcione?

En esencia, mi queja radica en el comportamiento del proceso de enlace dentro de UpdateModel .

Suponiendo que desea actualizar un formulario a través de un método de acción Save simple para el cual los campos de datos en el formulario reflejan un modelo en su base de datos, inicialmente para guardar la solicitud, podríamos obtener el modelo existente de la base de datos y luego actualizarlo. campos que se modificaron, se enviaron a través de FormCollection y luego se actualizaron con UpdateModel a nuestro modelo existente. Esta función, sin embargo, parece que cualquiera de las propiedades existentes en este objeto rellenado con base de datos se está "restableciendo"; y con eso quiero decir, se están configurando en nulo o valores de inicialización como si fuera un objeto completamente nuevo, a excepción de aquellos que coinciden con los de FormCollection .

Esto es un problema porque todas las propiedades existentes que existen en el objeto, pero no necesariamente existen en el formulario, como las colecciones u objetos secundarios, las fechas o los campos que no están orientados a la interfaz de usuario están vacíos, lo que le deja un medio lleno, más o un objeto menos inutilizable que no se puede guardar en la base de datos debido a que faltan todos los datos, incluida probablemente una pila de ID ahora establecida en 0.

Creo que este no es un comportamiento deseable, y UpdateModel solo debería actualizar las propiedades donde encuentre una coincidencia de propiedad en FormCollection . Esto significaría que no se tocarían todas las propiedades existentes, pero se establecerían las actualizaciones. Sin embargo, de lo que se ha deducido hasta ahora, obviamente este no es el caso: parece que crea una copia de una copia nueva del objeto, actualiza las propiedades del formulario y luego devuelve el nuevo objeto.

Finalmente, para ponerlo en perspectiva de cuánta carga es esto, la única forma realmente de evitarlo en un medio complejo y mantener toda su información de objeto existente es unir manualmente cada propiedad con la propiedad de formulario correspondiente a absolutamente Garantizamos que solo se están actualizando las propiedades que existen en el formulario.

Supongo,

1. Aquellos que están de acuerdo en que esto es por diseño, ¿es mi enfoque de la forma de casarse de la mejor manera?
2. O, ¿cómo has abordado esto en esto?

Por favor, siéntase libre de ofrecer sus opiniones sobre estos chicos, Gracias.

Aquí hay otra instancia de alguien que sufre de este problema:
¿Llamar a UpdateModel con una colección de tipos de datos complejos restablece todos los valores no vinculados?

Answer 1

Pero sigo teniendo problemas con la idea de representar todo mi modelo de objetos en un formulario, especialmente si, por ejemplo, tengo 2 objetos secundarios y un par de listas, no estoy seguro de cómo se podría mapear esto fácilmente; ¿Una pila de campos ocultos que representan todo el mapa de objetos? Simplemente parece extraño.

Para esto, necesitas mirar cosas como los SubControllers y RenderAction. Puedes buscar en Google esos. Yo uso RenderAction mucho. Me permite inyectar un widget en una página desde su propio método de controlador, sin tener que insertar datos separados en ViewData.

No creo que uno deba tener que garantizar tan pronto cualquier información que desee actualizar a su modelo de base de datos, debe existir completamente en el formulario. No creo que tenga una tabla db que pueda facilitar esto, considere una "fecha de creación", por ejemplo, o una "fecha actualizada", no creo que sea ideal almacenar esto en un campo oculto en el formulario.

Tienes razón en eso. Cosas como CreationDate, UpdatedBy deben manejarse en el Controlador (en realidad, el repositorio, si está usando repositorios). Para ese momento, ya debería tener todos los campos que necesita del modelo de vista para actualizar su base de datos.

Es posible que tenga que usar objetos de "modelo de vista de tipo fuerte". Si no lo está o no está seguro, revise esta página: http://nerddinnerbook.s3.amazonaws.com/Part6.htm

Answer 2

Creo que tienes razón sobre el comportamiento de UpdateModel.

Sin embargo, ASP.NET MVC sigue un modelo de "ida y vuelta", lo que significa que su formulario ya debe contener todos los campos que necesita para producir un registro completo, ya sea porque introdujo valores para todos los campos en la vista, o bien están pidiendo todos los campos del usuario.

Este concepto de ida y vuelta es muy importante. Recuerde que en un verdadero modelo MVC no hay concepto de estado. Recupera datos de una tabla de la base de datos, coloca estos datos en una vista, los datos se muestran al usuario y el programa se detiene. El usuario edita los datos, hace clic en el botón de publicación, la vista publica los datos en un método del controlador, los datos se guardan en la base de datos y el programa se detiene. No hay dependencias en absoluto de una operación a la siguiente.

Esta práctica de no mantener un estado parcial de registros y estructuras de datos hace que sea muy sencillo escribir aplicaciones que se escalan bien y se comportan bien (particularmente con respecto a cosas como el botón de retroceso en el navegador).

Answer 3

El comportamiento que está experimentando con UpdateModel () suena como si estuviera enlazado a una lista, en cuyo caso UpdateModel () eliminará el contenido de la lista y la volverá a llenar. Ver el blog de Hanselman para una discusión sobre esto. Si está actualizando un solo objeto, UpdateModel () actualizará ese objeto individual, dejando las propiedades que no tienen un valor de formulario correspondiente tal como está.

Muchos de estos problemas se reducen a que UpdateModel () realmente pretende repoblar los modelos de vista, no los modelos de dominio, basados ​​en la entrada de formularios. (Estoy simplificando un poco las cosas al decir que un modelo de vista es solo un contrato entre un controlador y la vista, mientras que su modelo de dominio puede ser un objeto de modelo LINQ2SQL o EF). Todos los tutoriales y demostraciones de MVC muestran que UpdateModel () Se usa contra objetos de la base de datos, lo que me parece desafortunado, ya que es algo engañoso en cuanto al propósito previsto del enlace del modelo. La publicación de Robert es más indicativa de la intención real de UpdateModel ().

Answer 4

Yo uso UpdateModel bastante felizmente para los tipos que no están en la lista. Siempre tengo cuidado de especificar la matriz includeProperties (no por el potencial de este problema, sino por la seguridad, ¿desea que el usuario pueda piratear el formulario (muy fácil) y enviar las fechas, etc.?).

Eso no quiere decir que no se pueda mejorar más.

Además, un punto práctico a tener en cuenta al establecer los requisitos: para un servidor web que recibe un POST, un campo vacío es lo mismo que un campo inexistente . Eso significa que si UpdateModel se diseñara de manera tal que no "reiniciara" los campos de formulario inexistentes (como la fecha), el mismo comportamiento significaría que si el usuario elimina el texto en su campo de fecha y publicaciones, no se actualizará con vacío (o nulo).

James