asp.net mvc helpers fuertemente tipados: ¿su objeto vinculante debe ser el mismo que el objeto contable?

Question

veo que asp.net mvc 2 ha sido fuertemente tipado y al principio parece que funciona, creo que tal vez estoy haciendo algo mal en asp.net mvc 1 en términos de enlace de datos para renderizar la vista y publicar de nuevo en el controlador.

A menudo tengo diferentes objetos para representar la vista y publicar de nuevo en el controlador. Esto esta mal ?? Parece natural que al renderizar la vista, a menudo tenga un modelo de vista que tenga listas para desplegables, etc., pero para su publicación solo desea las propiedades que se necesitan para publicar de nuevo.

por ejemplo, en la forma en la prestación de, mi modelo de vista podría tener este aspecto

public class PersonViewModel 
{ 
     public int Age; 
     public string FIrst; 
     public JobCategory[] JobCategories; 
     public Sport[] Sports; 
     public int NumberOfChildren; 

} 

en este caso, jobCategories y Deportes va a ser utilizado para llenar un cuadro desplegable. NumberOfchildren va a ser html puesto y no quiero que se pueda editar. Cuando quiero publicar yo sólo quiero pasar de nuevo un objeto delgado con sólo las propiedades publicadas, así que tengo otro objeto

public class PersonUpdater 
{ 
     public int Age; 
     public string FIrst; 
     public int JobCategoryId; 
} 

éstas son las únicas propiedades que tengo que pasar de nuevo por lo que mi controlador se verá así:

public ActionResult Update(PersonUpdater personUpdater) 
{ 
     _repository.UpdateModel(personUpdater). 
} 

así, dado lo anterior, suponiendo que los métodos de ayuda inflexible de tipos (abajo) parecen útiles para la forma en la continuación, pero puede causar problemas en la fijación de vuelta al servidor si está referrring a diferentes propiedades.

http://weblogs.asp.net/scottgu/archive/2010/01/10/asp-net-mvc-2-strongly-typed-html-helpers.aspx

alguna idea?

Answer 1

El problema real es que el enfoque aceptado actual ignora SRP para ver modelos un poco: el formulario de edición actúa como entrada y salida simultáneamente.

La gente no ha aceptado todavía dividir en view model, como yo los llamo, input view model y output view model (para muchos - incluso la creación de view model capa es demasiado). Por lo tanto, actualmente, Mvc2 no tiene soporte para esto (no se supone que haya escrito fuertemente la vista que no es entrada ni salida al mismo tiempo) principalmente debido a la vaguedad y la falta de enfoques ampliamente aceptados.

Pero creo que hay una ganancia (bien ... en realidad es una compensación) en ir más profundo y separando view model en 2 de ellos. Y no me sorprendería que esta idea evolucione y, finalmente, sea ampliamente aceptada.

En realidad, el enfoque actual incluso tiene un nombre - Thunderdome principle. Y si tipos como Jeremy D. Miller dicen que esto es correcto, la comunidad no se molestará y no buscará nada más.

---

Desde el punto de vista práctico - algunos de los problemas que puede mitigar mediante el suministro de metadatos correctos (es posible que desee comprobar hacia fuera fluent model metadata provider).

Answer 2

Puede especificar a qué propiedad se refiere en un helper fuertemente tipado, busque la sobrecarga con 3 parámetros.

Nada malo con su método. Las vistas fuertemente tipadas están ahí para ayudarlo a desarrollarse mejor, por lo que ningún typpo puede interferir en su camino.

Answer 3

La mayor parte del tiempo las cosas de encuadernación automática no se ajustan a lo que necesito, así que solo recurro a publicar en un parámetro formCollection y voy a manual. Si puede usar cualquier parte de la magia de encuadernación del modelo, entonces será mejor para usted.

El enlace menos no significa que se envían menos datos al servidor. Todos los elementos de entrada en el formulario serán transmitidos, simplemente no los verá como parámetros discretos, fuertemente tipados, "automáticos". Si realmente quieres adelgazar los datos de la publicación, debes restringir qué elementos de entrada están dentro del formulario particular que publicas. MVC sigue siendo HTTP después de todo ...

Answer 4

Sugeriría mantenerlo simple simplemente usando un objeto para GET y POST. La mantenibilidad del código es mucho más importante/valiosa aquí que guardar unos pocos bytes para una acción de actualización.

Arnis hace buenos argumentos con respecto a SRP y otros patrones de diseño, pero se supone que las petterns se deben adaptar. Si fuera usted, usaría la ayuda que el framework mvc ha creado para usted: use los helpers escritos; use objetos tipo modelo/viewmodel para GET/POST y si necesita un enlace más complejo, cree un enlace personalizado.

Mantenga su código ligero y su aplicación seguirá siendo increíble.

Answer 5

Utilizo un modelo de entrada (que se muestra en el formulario) y un modelo separado para la salida (publicado por el formulario). La validación se coloca en el modelo de salida. La razón específica por la que hago esto es por listas desplegables. Desea una lista de posibles valores para presentar al usuario y estos se encuentran en el modelo de entrada. En la salida o publicación del formulario no deseo la lista de posibles valores, quiero saber qué valores seleccionó el usuario, si corresponde.

Answer 6

Uso los modelos de vista separada para la entrada [GET] y la salida [POST] también, a menos que los dos modelos sean idénticos. En mi humilde opinión, este enfoque es más limpio, más fácil de mantener y expresa con mayor claridad qué datos se actualizarán mediante una determinada acción del controlador.

Hay un costo en términos de LOC, pero el código adicional generalmente no es lógica. En la mayoría de los casos, no creo que la duplicación de algunas propiedades automáticas en dos objetos viole el principio DRY, y creo que el costo está justificado para seguir a SRP.

El otro costo, como habrás notado, es que los helpers incorporados fuertemente tipados no funcionan tan bien. ¿Has pensado en escribir tus propios ayudantes que respalden tu patrón? Por ejemplo, puede sobrecargar uno de los helpers existentes para que pueda especificar fuente (por ejemplo, la propiedad del modelo de entrada) y destino (por ejemplo, el nombre del campo de formulario que se publica en el modelo de salida))

Answer 7

Al observar su situación específica, se me ocurren los siguientes puntos.

1) Los dos modelos son muy similares en verdad 2) Si se agrega "MiddleName", hay que añadir que en dos lugares 3) Cuando se dice "Sólo quiero pasar de nuevo un objeto delgado" - el POST real contendrá la misma cantidad de datos, ya sea que se vincule con el modelo original o con uno nuevo (contendrá una clave, par de valores para cada entrada de usuario dentro del formulario) 4) Usted excluye la opción de mostrar los datos en su página "guardado bien" o "algo no válido" ya que no es parte del modelo

Por estas razones, recomendaría usar el mismo modelo para GET y POST de la acción.