route - Cómo migrar la aplicación asp.net existente al formato de patrón asp.net MVC
select asp-for asp-items (4)
Deseo migrar la aplicación asp.net existente al formato de patrón asp.net MVC ahora. ¿Qué procedimiento debo seguir? Cualquier instrucción paso a paso sería muy útil.
Mi respuesta sería "Tu no" :). Si realmente desea hacer esto, puede utilizar el sitio asp.net actual como su objetivo final, o como un ''documento'' de requisitos. Y tal vez puedas usar la capa de datos en tu modelo, pero tendrás que rediseñar todo el sitio.
Como Tomas ya señaló, es MUY diferente de asp.net clásico.
No creo que exista una "migración paso a paso" de ASP.NET WebForms a ASP.NET MVC. Son dos patrones de diseño completamente diferentes construidos en el mismo marco, pero hay (en la mayoría de los casos) una gran cantidad de cosas que no solo necesitan ser movidas, sino completamente rediseñadas, si no solo quiere construir una red aplicación en el proyecto de plantilla MVC en lugar de la plantilla de WebForms.
La razón principal de esto es la separación de las preocupaciones, que es mucho más estricta en MVC que en WebForms. Actualmente estoy trabajando (bueno, debería estar ...) en la migración de un proyecto de pasatiempo antiguo y bastante problemático de WebForms a MVC y mi enfoque ha sido básicamente "ver la funcionalidad, reconstruirla desde cero". Por supuesto, tenía algunos métodos de ayuda para formatear la salida, etc., que acabo de incluir en mi nuevo proyecto, pero la mayoría de las cosas básicas que elegí simplemente para rehacer por completo. Te sorprendería lo poco que me lleva alcanzar los mismos objetivos con MVC ahora, que configuré para la aplicación WebForms hace un año y medio - con el uso de Entity Framework, jQuery y otras cosas dulces, podrás generar resultados en un par de horas.
Esta es mi guía paso a paso, basada en los pasos que hemos tomado en mi empresa durante nuestro paso de un ASP.Net Webforms clásico a ASP.Net MVC. No es perfecto, y sigue en curso, ya que tenemos que hacer esto en etapas debido al tamaño del sitio, pero tal vez alguien más encontrará y presentará una respuesta mejorada en función de nuestros resultados.
Etapas: 1. Planificación: pasar a MVC desde Web Forms en ASP.Net requiere una planificación cuidadosa. El error que cometimos en nuestro movimiento no es darse cuenta de que hay realmente dos aspectos en esta etapa de planificación, planificación de ruta y planificación de modelo / controlador / acción. De lo contrario, se producirán problemas graves a medida que intente ampliar la funcionalidad de su sitio o realizar migraciones más complejas.
Sugerencias: - Mire su mapa del sitio actual y diseñe la estructura del mapa / directorio del sitio mejorada para usar en la aplicación ASP.Net MVC. Determine un ''idioma'' para su sitio web, por ejemplo, el comportamiento predeterminado de ASP.Net MVC es tener un comportamiento http: // nombre del sitio / {controlador} / {acción} / {id}, pero puede anular esto a medida que gana más experiencia en hackear las reglas de enrutamiento.
Recuerde que por defecto cada controlador se enrutará a través de un subdirectorio virtual de su aplicación, por ejemplo, http: // nombre del sitio / X dirigiría a XController (y de forma predeterminada su método de índice), http: // nombre del sitio / Y / Get haría la ruta a El método Get () de YController. Puede cambiar esto como lo desee (el enrutamiento es realmente poderoso), pero eso está más allá del alcance de esta respuesta.
Usando el mapa del sitio existente, especifique en qué carpeta de la estructura MVC debe caer cada página .aspx actual (por supuesto, primero pregunte si debería existir).
Si las secuencias de comandos, imágenes, etc. no se almacenan juntas, o en algunas carpetas de ''nombre reservado'' dentro de cada subdirectorio, considere hacerlo ahora cuando esté rediseñando. Esto es así porque simplificaría en gran medida su diseño al permitirle utilizar un comando de regla de enrutamiento Map.IgnoreRoute () en el archivo Global.aspx.cs para omitir el procesamiento de estas carpetas como rutas.
En nuestro caso, reflejamos el diseño de subdirectorio real del sitio actual, donde cada subdirectorio se convirtió en un controlador, por ejemplo, / La cuenta tendría un AccountController, / X tendría XController. Todas las páginas que cayeron dentro fueron reemplazadas por acciones dentro de cada controlador. por ejemplo, http: //sitename/profile/about.aspx ahora se convirtió en http: // nombre del sitio / profile / about y se correlacionó con el método "about" ActionResult dentro del profileController. Esto nos permite mantenernos ágiles realizando una migración parcial de uno o dos directorios (o varios archivos dentro de un directorio) a lo largo de una serie de sprints, en lugar de tener que migrar el sitio completo de una vez durante un período mucho más largo.
Cree una nueva aplicación ASP.Net MVC en Visual Studio e inmediatamente cree las reglas en el archivo Global.asax que ignoran las reglas de enrutamiento para las carpetas que existen en el sitio actual.
Copie las carpetas de la aplicación web ASP.Net a las carpetas de la aplicación ASP.Net MVC. Ejecute el sitio web y asegúrese de que funciona correctamente (debe hacerlo ya que aún no se utilizan reglas de enrutamiento).
Elija un subdirectorio o subconjunto de archivos dentro de un subdirectorio para migrar.
Para cada página .aspx dentro de este subdirectorio:
a. Crea su vista primero. Tiendo a usar la versión representada en el navegador web de la página como mi HTML base, y luego pongo marcadores de posición en las ubicaciones que sé que están llenas de datos dinámicos.
segundo. Usando los marcadores de posición para los datos dinámicos, cree un primer borrador del Modelo usando tipos de datos simples. Este modelo comenzará de manera simple, pero se refactorizará constantemente a medida que migre más páginas del sitio original, así que no se preocupe si comienza a parecer un poco pesado. Si se encuentra con demasiadas Propiedades en un Modelo para su gusto, o ve una agrupación lógica más allá del Modelo de cierto subconjunto de elementos, quizás esto sea un signo de que el Modelo necesita ser refactorizado para tener un objeto con estos datos simples tipos como propiedades pero está compuesto en la capa de lógica de negocios.
do. Cree el controlador si aún no se ha creado y coloque el método ActionResult apropiado para la Acción que su planificación ha determinado que debe enrutar a esta vista. Si se da cuenta de que hay una acción nueva que no se asigna a una página del sitio anterior, cree la Vista para el controlador e incluya las etiquetas // TODO: apropiadas para que pueda realizar un seguimiento de esto para implementarlo después de usted. han migrado las páginas existentes.
re. Considere agregar algún código de manejo para acciones desconocidas, si no tiene una regla de enrutamiento {* catchall} para esto que ya esté en su archivo global.asax.cs.
mi. Cree las clases de constructor para el Modelo de modo que, dados ciertos parámetros que tendrá el Controlador (pasados como su {id} o posiblemente un parámetro Request.QueryString de la URL, o un encabezado o cookie HTTP), el Modelo sabrá cómo Acceda a sus clases de lógica de negocios existentes y compile para que la Vista lo represente.
F. Vaya a la página siguiente en la lista y comience nuevamente desde el paso a.
Finalmente, cree la regla de enrutamiento que llamará a su nuevo Controlador y permita que se implementen las Acciones que ha escrito. Depurar, depurar, depurar ... Una vez que esté contento de que todo esté bien, elimine la carpeta existente y los archivos que ha migrado de su sitio principal, así como la regla IgnoreRoute en global.asax.cs.
Cree un redireccionamiento de la manera que prefiera si desea preservar la continuidad de los directorios y archivos antiguos (p. Ej., Es posible que los usuarios hayan marcado ya ciertas páginas en el sitio anterior).
Nota: Si mantiene los nombres exactos de los subdirectorios antiguos en su sitio MVC durante la fase de portado, es preferible migrar un subdirectorio completo en un momento en que me he dado cuenta, porque al hacer solo unos pocos archivos, las reglas de enrutamiento que necesita para escribir se vuelve más complejo ya que si existe una carpeta con el mismo nombre que la ruta de una regla de enrutamiento y esa carpeta tiene un archivo Default.aspx, (/ foldername /) se establecerá de forma predeterminada en la página Default.aspx, ya que requiere precidencia sobre el enrutamiento reglas.
Consejo: Considere seriamente el uso de una herramienta como RouteDebug para la depuración de rutas para que pueda descubrir cosas extrañas como las anteriores, o cuando tiene varias reglas de enrutamiento activadas y provoca comportamientos inesperados.
Este es mi primer borrador, por favor denme sus comentarios si me perdí algunos pasos o si ven agujeros en la guía, y modificaré la respuesta de manera apropiada.
Pueden estos pocos consejos adicionales ayudarán
- Reemplace <% - etiquetas de comentarios con @ *
utilice @ RenderSection ("Pie de página", falso) para @section footer {} y así sucesivamente, si tiene algún ContentPlaceHolder adicional, excepto el cuerpo principal en Ver qué RenderBody ().
todas las viejas etiquetas runat = "server" normales son inofensivas y no impiden la compilación y se pueden limpiar posteriormente
todos los controles Visibilidad que se controló fácilmente en código subyacente y marcado (Visible = "Verdadero") y controlados en código_detrás mediante el uso de Id de Control se deben refactorizar a la Colección ViewBag y bloques @if en la vista Razor.
también puedes ver este excelente curso de Pluralsight sobre este tema (3h 49m)