Diseño de acciones del controlador ASP.NET MVC

Question

Me gusta mucho el funcionamiento de ASP.NET MVC. Me encantaría implementarlo en todos los nuevos proyectos web que sigan adelante, pero el otro día me tocó un inconveniente en un prototipo para el que realmente no he encontrado una buena solución, así que te pregunto, ¿cómo diseñarías una aplicación MVC? que no se ajusta al patrón REST típico? Como ejemplo, el prototipo que estaba diseñando tendría varias páginas, pero las páginas mismas no están necesariamente vinculadas a un modelo de dominio. Por ejemplo, tener un sitio de registro simple, lo que podría tener las siguientes páginas:

• /Default.aspx
• /Register.aspx
• /ThankYou.aspx

De vez en cuando, como una el programa puede requerir una sección de administrador para tratar detalles tales como la moderación de registros o la revisión de datos. En una aplicación ASP.NET Web estándar, debo añadir lo siguiente

• /Admin/Default.aspx
• /Admin/ListRegistrations.aspx
• /Admin/ViewReports.aspx ...

¿sería una desviación inaceptable desde el patrón MVC, en este caso, para tener dos controladores como:

• Home-> Índice
• Inicio-> registrar
• Inicio-> ThankYou
• Administración-> Índice
• Administración-> ListRegistrations
• Administración-> Informes

Mi frustración con esto se ve agravado por el hecho de que todavía no existe una implementación real sólida de los subcontroladores y las áreas. Conozco el prototipo de "Áreas" creado por Phil Haack, pero no es muy maduro, y francamente, no estoy seguro de cómo me gusta la configuración, pero realmente no sé cómo me gustaría. para ver ese trabajo tampoco.

Supongo que cuando pienso en MVC, tiendo a pensar en REST también, y tener acciones de controlador que representen páginas en lugar de entidades o acciones reales no me sienta bien. ¿Qué piensas?

Answer 1

Siempre puede mezclar formularios Web ASP.NET con MVC.

Sólo tiene que añadir

routes.IgnoreRoute("Pages/{*path}"); 

a su tabla de enrutamiento y agregar páginas tradicionales formulario web para Pages carpeta de la aplicación.

Answer 2

Puede tener tantos controladores como tenga sentido; ese diseño parece razonable. Tenga en cuenta que las rutas no tienen para correlacionar directamente con {controller}/{action}, pero mantienen las cosas simples. Me parece bien - excepto que probablemente te agradecería como una vista - es decir, el Registro [GET] quizás utiliza una vista diferente para Registrarse [POST]

Answer 3

Un error que los recién llegados hacen a MVC es agrupar acciones en un controlador por motivos de visualización. En su caso, en lugar de agrupar las acciones Registrar y Agradecer con la página principal, intente separarlas en un AccountController como lo hizo el equipo MVC en el proyecto de muestra. Puede usar el enrutamiento para configurar la URL como desee para el usuario final.

En cuanto a sus otras acciones, ¿qué tal un ReportController? También podría tener un ControlController cuya acción/vista de índice contenga enlaces a varias acciones de administrador, incluidas las de ReportController.

Versión corta: Agrupe las acciones en un controlador por función, no en la navegación del sitio.

Answer 4

Normalmente abandono el controlador "Inicio" como la primera cosa en un proyecto y lo reemplazo con un controlador "Página". Lo uso para cualquier cosa que sea "solo" una página. Cosas como "Preguntas frecuentes", "Contáctenos", etc. Hago esto al menos parcialmente porque el enfoque predeterminado para el controlador Home requiere que se agregue un nuevo método cada vez que necesite incluso una página básica y estática.

En ese controlador, solo tengo una acción: Mostrar. Esa acción da a todas esas páginas el mismo objeto de contexto. De hecho, almaceno el contenido de esas páginas en la base de datos con una búsqueda "slug" y lo vinculo a plantillas de NVelocity, pero incluso solo plantillas HTML estáticas o NVelocity en archivos también funcionarían.

Cualquier otra cosa, como dicen los demás, se divide en controladores por la "cosa" que se maneja. Entonces, ReportController, User o AccountController, CartController, etc. Entonces las acciones tienen mucho más sentido.

Cuando habla de listar los usuarios registrados, en realidad es una lista de usuarios, por lo que tendría un UserController y do/User/Display/Registered/MostRecent o algo similar. Para el registro en sí,/User/Register que se publicaría en/User/SaveRegistration, que a su vez podría redirigir a/User/DisplayProfile/NewUserID o/Page/Display/Home desde allí.