Enrutamiento MVC3 con WebForms

Question

Tengo una solución que usa WebForms .Net 4.0. Estoy planeando utilizar MVC3 en la misma solución. Seguí a Scott Hanselman blog y las cosas estaban sucediendo.

Tengo que admitir que soy bastante nuevo en esto. Sin embargo, parece que me falta una gran parte de cómo funcionan realmente las rutas con respecto a los espacios de nombres.

En la actualidad, nuestra solución tiene la siguiente:

WebApplicatin: 
    Accounting 
     Receivables 
     ReceivablesGrid.aspx 
     ReceivableForm.aspx 
     Payables 
     PayablesGrid.aspx 
     PayablesForm 
..etc. 

Por lo tanto, se puede solicitar una página usando

Domain/Accounting/Receivables/ReceivablesGrid.aspx 
Domain/Accounting/Receivables/ReceivableForm.aspx?Key=1 
Domain/Accounting/Payables/PayablesGrid.aspx 
Domain/Accounting/Payables/PayablesForm.aspx?Key=1 

....

Estoy planeando añadir otra capa a parecerse a MVC.

WebApplicatin: 
     Accounting 
      Receivables 
      ReceivablesGrid.aspx 
      ReceivableForm.aspx 
      Mobile 
       Controllers 
       ReceivableConroller.cs 
       Models 
       Views 
       Receivables 
        Index 
        Update 
        Edit 
        Create 
      Payables 
      PayablesGrid.aspx 
      PayablesForm 
      Mobile 
       Controllers 
       PayablesConroller.cs 
       Models 
       Views 
       Payables 
        Index 
        Update 
        Edit 
        Create 

    ..etc. 

Por supuesto, estos no son los nombres reales. Sin embargo, traté de hacerlo lo más cercano posible a mi situación. Desafortunadamente, sería mejor si sigo esto porque podría usar parte de la lógica que podría agregarse en el mismo espacio de nombres. Además, crear carpetas en la raíz para parecerse a los Controladores, Vistas, Modelos no funcionaría con mi solución.

En Global.asax, añadí una ruta como tal:

routes.MapRoute(
     "AccountingReceivablesMobile", // Route name 
     "Accounting/Receivables/Mobile/{controller}/{action}/{id}", 
     new { controller = "Home", action = "Index", id = UrlParameter.Optional }); 

routes.MapRoute(
     "AccountingPayablesMobile", // Route name 
     "Accounting/Payables/Mobile/{controller}/{action}/{id}", 
     new { controller = "Home", action = "Index", id = UrlParameter.Optional }); 

Otra solución que acabé tratando es mediante la extensión de la RazorViewEngine. En el constructor del nuevo motor, establecí dos propiedades de la siguiente manera:

base.ViewLocationFormats = new string[] { "~/Accounting/Receivables/Mobile/Views/{1}/{0}.cshtml", 
"~/Accounting/Payables/Mobile/Views/{1}/{0}.cshtml" 
}; 

base.MasterLocationFormats = new[] { "~/Views/Shared/{0}.cshtml"}. 

esto funcionó bastante bien. Sin embargo, siento que agregar esas rutas no es tan escalable como agregar un formulario web. Mi problema es que realmente no quiero agregar una ruta para cada ruta posible. Esto significa que tendré otra ruta o entrada a la matriz cuando agregue una nueva vista. Entonces, ¿cómo puedo hacer esto más simple? ¿Qué estoy haciendo mal? Miré a Areas sin embargo, parece forzar a crear una carpeta de Áreas y poner dentro de ella.

Gracias,

Answer 1

Debido a que ASP.NET MVC (así como rieles y muchas otras implementaciones de MVC) se basan en las convenciones más configuración, el marco realmente quiere tener las \controllers, \views y directorios en el raíz del sitio. El trabajo que está haciendo para que el motor de enrutamiento recoja su desviación de las convenciones es precisamente lo que MVC intenta evitar.

Podría extender una porción del marco, como sus pruebas con el motor Razor ... Pero personalmente, abrazaré las convenciones del marco de trabajo, lo que hace que algunos escenarios como los que encuentre resulten un poco complicados, pero sé que otro desarrollador con un breve conocimiento de ASP.NET MVC puede abrir el código y encontrar el área de preocupación que necesita de inmediato. Anidar esas basadas en la convención carpetas en otras carpetas haría que no fuera tan obvio, a menos que se definieran como áreas MVC.

Tengo dos soluciones de producción que son híbridas de ASP.NET WebForms y MVC3.En ambos casos, opté por el enfoque predeterminado (controlador, modelo, ver carpetas en la raíz) y comencé a refacturar mi base de código de formularios web heredados para utilizar estándares modernos como el patrón de repositorio y mover la lógica comercial común a un "servicio" espacio de nombres o un nuevo ensamblaje en la solución.

Al retroceder para refactorizar su código para posiblemente usar interfaces para clases de lógica/repositorio de negocios (estoy asumiendo que no lo hace actualmente, porque la mayoría de las personas no usaban formularios web), puede usar Ninject o otro contenedor IoC para facilitar el cableado de esta lógica (er) tanto en los formularios web heredados como en los controladores MVC, lo que permite una mejor estructura y un único punto de preocupación; normalmente en su App_Start().

Con respecto a estar fuera del espacio de nombre, una herramienta de productividad como ReSharper o CodeRush detectará automáticamente y completará su declaración using si escribe código en otro espacio de nombres.

Sé que esta no es la respuesta que está buscando y que algunos pueden estallar, pero creo que es importante dar un paso atrás y ver lo que está tratando de resolver. Complicar la arquitectura básica de MVC para que se ajuste a su escenario me haría esperar o no si no tuviera el tiempo/los recursos para refactorizar alguna lógica de operaciones heredada o adoptar las convenciones cocidas; Comience con un par de controladores simples para eliminar los puntos débiles en su aplicación de formularios web y, si el tiempo lo permite, comience a transferir las páginas a MVC. El interino puede no ser bonito, pero será simple.

Esta es una muy buena pregunta e hiciste un gran trabajo investigando tus opciones extendiendo Razor. Me interesa ver si alguien más piensa en desviarse de las convenciones estándar de la carpeta MVC. Tal vez solo soy exigente?

Lo último a verificar, si su objetivo principal principal es hacer que su sitio esté habilitado para dispositivos móviles, es this article por Steve Sanderson. Aprovecha el excelente ensamblaje 51Degrees.mobi para la detección de dispositivos móviles y cubre el uso dentro de ASP.NET y ASP.NET MVC. Sanderson también tiene una publicación similar en su blog personal sobre el mismo tema.