Los controladores no solo se encargan de retornar resultados, ellos también deben recibir datos más allá de lo que el sistema de routing les presenta, por ejemplo un usuario puede estar creando una entrada para un blog, el controlador debe recibir estos datos y según su programación ver que hace con ellos y que retorna.
Parámetros de las Acciones
Las acciones del controlador no son más que otro método en una clase ASP.NET, esto significa que tienen la potestad de indicarle al framework como debe llenar sus campos, inclusive utilizando los datos que recibe por request.
Esto que explicamos es lo que se llama model binding algo que se traduciría como unión al modelo. Veamos ahora en la siguiente imagen como podemos crear una acción que trabaje con el request de forma tradicional:
En el ejemplo vemos como tomamos los valores que necesitamos del mismo objeto request directamente, inclusive podemos tomarnos la atribución de convertir los valores en el tipo de datos que necesitamos almacenar como vemos en las 3 últimas asignaciones de valores.
Model Binding
El model binding nos ahorra las desventajas que vimos en el ejemplo anterior, esto es gracias a que en vez de recibir directamente los valores del request, lo que hacemos es declararlos como parámetros.
Veamos el ejemplo a continuación para explicar con mayor detalle su funcionamiento:
Acá vemos que en vez de utilizar el objeto request, simplemente le decimos a los atributos que su valor va a corresponder al valor que tengan los parámetros, estos parámetros a su vez van a obtener su valor directamente del objeto request.
Como vemos este enfoque es más robusto ya que utiliza al framework para que haga las diferentes comprobaciones que en otro caso debería realizar el desarrollador, esto hace que se escriba menos código y que la aplicación sea más legible.
Veamos el siguiente ejemplo donde se utiliza el valor de la URL simplemente declarando el parámetro con el mismo nombre para que el framework pueda asociarlo:
En la imagen el ejemplo recibiría el valor del parámetro id de una URL que tuviese una forma /auctions/auction/45 por ejemplo, ya que en nuestro archivo de routing habremos definido que ese patrón llamaría a esta acción del controlador y que lo que se reciba sería enviado con el identificador id.
Finalizando el tutorial tenemos más claros los conceptos de cómo funcionan las acciones de un controlador y cómo podemos recibir datos que nos permitan elaborar una lógica en nuestra aplicación.
Parámetros de las Acciones
Las acciones del controlador no son más que otro método en una clase ASP.NET, esto significa que tienen la potestad de indicarle al framework como debe llenar sus campos, inclusive utilizando los datos que recibe por request.
Esto que explicamos es lo que se llama model binding algo que se traduciría como unión al modelo. Veamos ahora en la siguiente imagen como podemos crear una acción que trabaje con el request de forma tradicional:
En el ejemplo vemos como tomamos los valores que necesitamos del mismo objeto request directamente, inclusive podemos tomarnos la atribución de convertir los valores en el tipo de datos que necesitamos almacenar como vemos en las 3 últimas asignaciones de valores.
Recordar
La desventaja mayor de este enfoque, es que deja la carga de toda la responsabilidad del lado del desarrollador, por lo que debemos generar más código y hacer más validaciones.
Model Binding
El model binding nos ahorra las desventajas que vimos en el ejemplo anterior, esto es gracias a que en vez de recibir directamente los valores del request, lo que hacemos es declararlos como parámetros.
Veamos el ejemplo a continuación para explicar con mayor detalle su funcionamiento:
Acá vemos que en vez de utilizar el objeto request, simplemente le decimos a los atributos que su valor va a corresponder al valor que tengan los parámetros, estos parámetros a su vez van a obtener su valor directamente del objeto request.
Importante
Al obtener los valores del objeto request es importante para los parámetros mantener el nombre, ya que ASP.NET MVC va a intentar llenarlos utilizando el nombre del parámetro para ubicar el recurso en el request.
Como vemos este enfoque es más robusto ya que utiliza al framework para que haga las diferentes comprobaciones que en otro caso debería realizar el desarrollador, esto hace que se escriba menos código y que la aplicación sea más legible.
Importante
El objeto request no es lo único que nos permite utilizar el model binding como fuente de datos, podemos utilizar también objetos serializados con JSON o también datos que provengan de un formulario HTML o inclusive de la misma URL.
Veamos el siguiente ejemplo donde se utiliza el valor de la URL simplemente declarando el parámetro con el mismo nombre para que el framework pueda asociarlo:
En la imagen el ejemplo recibiría el valor del parámetro id de una URL que tuviese una forma /auctions/auction/45 por ejemplo, ya que en nuestro archivo de routing habremos definido que ese patrón llamaría a esta acción del controlador y que lo que se reciba sería enviado con el identificador id.
Finalizando el tutorial tenemos más claros los conceptos de cómo funcionan las acciones de un controlador y cómo podemos recibir datos que nos permitan elaborar una lógica en nuestra aplicación.
