vista net mvc modelo introduccion desarrollo datos crear controlador contexto con clase asp model-view-controller controller

model view controller - net - En el desarrollo del juego, ¿el controlador en MVC es puramente para tratar con la entrada del usuario?



introduccion a mvc (6)

No necesariamente. El controlador puede procesar la entrada del usuario, actualizar su modelo y quizás decidir devolver directamente un resultado JSON o incluso una imagen generada dinámicamente en lugar de una página de visualización.

El controlador también puede decidir el flujo de página. Un usuario hace clic en un enlace de "mi cuenta" en su sitio web pero aún no ha iniciado sesión, por lo que se le dirige a una página de inicio de sesión. Después de un inicio de sesión exitoso, el controlador puede decidir redirigirlos a la página "mi cuenta" a través de un parámetro de consulta ReturnUrl o no.

También podría poner la lógica de validación en su controlador, pero no sugeriría este enfoque para proyectos más grandes. Esa lógica pertenece a tu modelo.

He leído cosas contradictorias sobre esto.

De la Wikipedia:

Controlador Procesa y responde a eventos, típicamente acciones del usuario, y puede invocar cambios en el modelo.

Es la palabra TÍPICAMENTE que es confusa. Si no es solo la entrada del usuario, ¿qué más?


No, se debe usar para TODAS las interacciones entre el Modelo y la Vista (la pantalla de la IU). Esto incluye la visualización de datos en la pantalla UI (actualizando la pantalla) recuperada del Modelo, así como responder a las entradas / interacciones del usuario con la pantalla UI ...

también podría incluir la actualización de la pantalla UI como resultado de cambios en el modelo (en los datos) por las acciones de estos usuarios en OTRAS pantallas, o (en un sistema concurrente multiusuario), otras acciones de los usuarios en los datos en el repositorio (base de datos)


La responsabilidad del controlador es administrar el flujo de aplicaciones. Maneja las solicitudes, compone los modelos / vistas / ayudantes apropiados y opcionalmente emite una respuesta.

Las solicitudes pueden originarse de muchas fuentes diferentes, como servicios web y locales, eventos temporizados y más.


Llamo validar y desinfectar la entrada del usuario como parte de la vista.

Llamo lógica al controlador, la parte que toma los datos validados y desinfectados, y funciona con eso. De esta forma, puede escribir un arnés de prueba que actúa como vista, que suministra datos al controlador y prueba los resultados.


No. En el patrón clásico, el controlador podría obtener entradas de cualquier fuente. Para los frameworks MVC basados ​​en la web como Ruby / Rails o ASP.NET MVC, el controlador obtiene su entrada de los parámetros de consulta y formulario.

Más información sobre MVC en http://en.wikipedia.org/wiki/Model-view-controller

EDITAR : cuando digo entradas de cualquier fuente, estoy pensando en una aplicación que puede tener una GUI y otras interfaces para las fuentes de entrada, por ejemplo, un subsistema de sensores que interactúa con un controlador para actualizar el modelo.

EDITAR : en función de su actualización, un controlador podría responder a eventos de red si el juego fuera un juego multijugador en Internet. Estos no serían manejados por el controlador para el dispositivo de entrada del usuario.


Veo el controlador como un Coordinador , la mayor parte de mi código generalmente está en el controlador. Aquí es donde suceden la mayoría de las sucursales. En una Vista o Modelo, la mayor parte de su código se va a tratar solo (un objeto de datos no sabe nada sobre un objeto de vista). Sin embargo, un controlador combina un objeto de datos (modelo) con un objeto de vista, por lo tanto, pienso en él como coordinador .

Una ''prueba'' general puede aplicarse a su aplicación para ver si están siguiendo MVC lo suficiente: ¿Es muy fácil volver a aplicar la apariencia de su aplicación? (Cambie la vista sin volver a escribir un montón de código).

No se deje atrapar por todos los debates religiosos y las "reglas" rígidas que rodean a MVC, un producto que genera dinero siguiendo solo el 80% de las ''reglas'' de MVC es mejor que un producto que aún no está hecho y demasiado complejo como para corre bien ...