none
Duda sobre si utilizar asp.net mvc o web forms RRS feed

  • Pregunta

  • Hola a todos,

    Tengo una duda sobre si utilizar asp.net mvc o web forms para un proyecto que estoy realizando. Explico un poco de que va el proyecto para que me aconsejeis sobre lo que debería utilizar:

    Se trata de una aplicación web que permitirá manejar remotamente a través de internet un robot. La aplicación constará de 2 partes diferencias:

    1) Parte usuario:

    Para acceder a la aplicación hay que ser un usuario registrado. Una vez registrado se podrá:

    - Ver una galería multimedia donde se almacenan las imágenes o vídeos que el usuario haya querido guardar mientras usaba el robot (el robot envía vídeo a la aplicación a través de una cámara) y gestionar dicha galería

    - Consultar las últimas trayectorias realizadas por el robot.

    - Configurar la potencia de motores, ángulos de giro... del robot

    2) Parte manejo del robot:

    - Es como un teclado en pantalla que muestra las opciones del robot, es decir, flechas direccionales (manteniendo pulsando se mueve en un sentido u otro), lectura de sensores, nivel de la batería... Además del vídeo en tiempo real que obtiene el robot

     

    La duda me surje a raíz de que para la parte 2 hago uso de sockets para transmitir las ordenes al robot vía wifi y no sé muy bien si encaja dentro de un modelo MVC.

    Gracias, Un Saludo

    martes, 24 de agosto de 2010 18:46

Respuestas

  • Veamos si puedo ayudarte :)

    La duda me surje a raíz de que para la parte 2 hago uso de sockets para transmitir las ordenes al robot vía wifi y no sé muy bien si encaja dentro de un modelo MVC

    Veamos, si no te encaja dentro de un modelo MVC tampoco te debe encajar dentro de un modelo de WebForms... En el fondo el modelo de aplicación es el mismo: una aplicación web que se ejecuta en cualquier browser a través de HTML+Javascript. Difieren (y mucho) en como construímos la aplicación, pero el modelo de aplicación final és idéntico.

    Has pensado como usuarías los sockets a través de Webforms? Seguramente tendrías diversos botones y en los eventos Click (que se ejecutan en servidor) abrirías un socket hacia el robot y enviarías el comando... Bien, y eso en que se traduce realmente? Pues cuando el usuario hace click al botón, se ejecuta un postback, que no es nada más que una petición HTTP (en POST) con diversos datos (entre ellos el botón que se ha pulsado). Esta petición es recogida y entendida por el runtime de asp.net webforms en el servidor web y gracias a estos diversos datos que se mandan, sabe que botón se ha pulsado y invoca tu código para el Click. Allí tu abres un socket, envías comandos al robot, modificas los controles de la página y terminas. Cuando "terminas" que ocurre? Pues bien que desde el servidor se manda la respuesta al cliente. Recuerda que el cliente (browser) ha hecho una petición HTTP, por lo que espera una respuesta. Dicha respuesta es la que se envía cuando tu código del Click termina y es el HTML de la misma página en la que estabas (el HTML puede haberse modificado si tu has modificado los valores de los controles). Esto es (muy simplificado) como funciona webforms.

    Y en MVC? Pues es muy parecido: en el HTML habrá un botón (salvo que no será un <asp:Button> sinó directamente un <input> que añadirás en el código de la vista) y en su evento click de javascript abrirás una petición HTTP y mandarás los datos que tu quieras al servidor. Estos datos serán recogidos por un controlador, quien abrirá el socket, recojerá datos, creará un ViewModel y enviará dicho ViewModel a una vista... El resultado es un conjunto de HTML nuevo que se envía al cliente.

    Lo ves? Es el mismo modelo!

    1. Petición del cliente al servidor para indicar que el usuario ha pulsado un botón en concreto
    2. Ejecución en servidor de un socket y recogida de resultados
    3. Generación en servidor de un HTML con los resultados
    4. Envío del HTML al cliente (como respuesta a la petición del punto 1)

    Por lo tanto, usar sockets o no es irrelevante a la hora de decidir entre webforms o MVC. La decisión entre webforms y MVC depende de otros factores (mantenabilidad de código, conocimientos previos, testeablidad del código).

    P.ej. yo nunca opto por Webforms. Desde mi punto de vista no tienen sentido y lían más que ayudan. Yo siempre uso MVC (pero esta es mi opinión).

    En tu caso, antes, plantéate una cosa: Quieres realmente una aplicación web? Este es la decisión real que creo que debes tomar.

    En mi opinión, por lo que dices (connexión con un robot a través de sockets, cámaras en tiempo real, ...) podría ser mucho mejor una aplicación nativa (winforms, wpf) antes que una aplicación web. Lo que quieres hacer se puede hacer con una aplicación web, sólo te digo que te plantees si es lo mejor (no conozco todos tus condicionantes para ayudarte en tu elección).

    Un saludo!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis
    • Marcado como respuesta brian bachicha viernes, 27 de agosto de 2010 9:37
    viernes, 27 de agosto de 2010 8:55

Todas las respuestas

  • Veamos si puedo ayudarte :)

    La duda me surje a raíz de que para la parte 2 hago uso de sockets para transmitir las ordenes al robot vía wifi y no sé muy bien si encaja dentro de un modelo MVC

    Veamos, si no te encaja dentro de un modelo MVC tampoco te debe encajar dentro de un modelo de WebForms... En el fondo el modelo de aplicación es el mismo: una aplicación web que se ejecuta en cualquier browser a través de HTML+Javascript. Difieren (y mucho) en como construímos la aplicación, pero el modelo de aplicación final és idéntico.

    Has pensado como usuarías los sockets a través de Webforms? Seguramente tendrías diversos botones y en los eventos Click (que se ejecutan en servidor) abrirías un socket hacia el robot y enviarías el comando... Bien, y eso en que se traduce realmente? Pues cuando el usuario hace click al botón, se ejecuta un postback, que no es nada más que una petición HTTP (en POST) con diversos datos (entre ellos el botón que se ha pulsado). Esta petición es recogida y entendida por el runtime de asp.net webforms en el servidor web y gracias a estos diversos datos que se mandan, sabe que botón se ha pulsado y invoca tu código para el Click. Allí tu abres un socket, envías comandos al robot, modificas los controles de la página y terminas. Cuando "terminas" que ocurre? Pues bien que desde el servidor se manda la respuesta al cliente. Recuerda que el cliente (browser) ha hecho una petición HTTP, por lo que espera una respuesta. Dicha respuesta es la que se envía cuando tu código del Click termina y es el HTML de la misma página en la que estabas (el HTML puede haberse modificado si tu has modificado los valores de los controles). Esto es (muy simplificado) como funciona webforms.

    Y en MVC? Pues es muy parecido: en el HTML habrá un botón (salvo que no será un <asp:Button> sinó directamente un <input> que añadirás en el código de la vista) y en su evento click de javascript abrirás una petición HTTP y mandarás los datos que tu quieras al servidor. Estos datos serán recogidos por un controlador, quien abrirá el socket, recojerá datos, creará un ViewModel y enviará dicho ViewModel a una vista... El resultado es un conjunto de HTML nuevo que se envía al cliente.

    Lo ves? Es el mismo modelo!

    1. Petición del cliente al servidor para indicar que el usuario ha pulsado un botón en concreto
    2. Ejecución en servidor de un socket y recogida de resultados
    3. Generación en servidor de un HTML con los resultados
    4. Envío del HTML al cliente (como respuesta a la petición del punto 1)

    Por lo tanto, usar sockets o no es irrelevante a la hora de decidir entre webforms o MVC. La decisión entre webforms y MVC depende de otros factores (mantenabilidad de código, conocimientos previos, testeablidad del código).

    P.ej. yo nunca opto por Webforms. Desde mi punto de vista no tienen sentido y lían más que ayudan. Yo siempre uso MVC (pero esta es mi opinión).

    En tu caso, antes, plantéate una cosa: Quieres realmente una aplicación web? Este es la decisión real que creo que debes tomar.

    En mi opinión, por lo que dices (connexión con un robot a través de sockets, cámaras en tiempo real, ...) podría ser mucho mejor una aplicación nativa (winforms, wpf) antes que una aplicación web. Lo que quieres hacer se puede hacer con una aplicación web, sólo te digo que te plantees si es lo mejor (no conozco todos tus condicionantes para ayudarte en tu elección).

    Un saludo!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis
    • Marcado como respuesta brian bachicha viernes, 27 de agosto de 2010 9:37
    viernes, 27 de agosto de 2010 8:55
  • Hola eduard,

    Antes de nada muchas gracias por dedicar un rato de tu tiempo a echarme una mano. El condicionante de este proyecto es que tiene ser una aplicación web, para que de este modo se puede acceder y controlar la aplicación desde cualquier lugar.

    Al final me he decido por utilizar aps.net mvc porque posiblemente la complejidad de la aplicación crecerá en un futuro y para ir añadiendo cosas es mucha más sencillo de este modo.

    Las comunicaciones las haré como bien indicas, haciendo uso de javascript (con jquery) y con un controlador encargado de manejar los sockets. Usando jquery me simplificará bastante más las cosas, ya que puedo capturar cualquier evento sobre cualquier elemento de la página (click o pulsaciones (mousedown+mouseup)) y llamar a la función encargada de manejar dicho evento en el controlador de comunicaciones.

    Muchas gracias otra vez y un saludo!

    viernes, 27 de agosto de 2010 9:37
  • De nada... para eso estamos :)

    Ya sabes, si tienes cualquier duda sobre MVC, no te cortes... intentaremos resolverla lo mejor que sepamos!

    Un saludo!!!! :)


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis
    lunes, 30 de agosto de 2010 12:11