2008-09-27 11 views
5

Una cosa que realmente ha estado dificultando la vida en ponerse al día sobre la base de código en un proyecto clásico ASP es que la situación de archivo de inclusión es un desastre. A veces encuentro que la función que estaba buscando estaba incluida en un archivo de inclusión que no tiene relación alguna. ¿Alguien tiene algún consejo sobre cómo refactorizar esto de modo que uno pueda decir más fácilmente dónde está una función si la necesitan?Refactorización "incluye archivo infierno"

EDIT: Una cosa que olvidé preguntar: ¿vbscript tiene algún tipo de mecanismo para evitar que un archivo se incluya dos veces? Sorta como # ifndef de C?

Respuesta

14

Hay algunas cosas básicas que puede hacer al hacerse cargo de una aplicación ASP clásica, pero es probable que termine lamentando haberlas hecho.

  1. Eliminar archivos de inclusión duplicados. Cada aplicación ASP clásica que he visto en mi vida tiene 5 páginas "login.asp" y 7 archivos "datepicker.js", entre otras. Busque y elimine todos los duplicados, y luego cambie las referencias en el resto de la aplicación según sea necesario. Tenga cuidado de hacer una comprobación de diferencias en cada archivo a medida que lo elimina; a menudo los archivos duplicados tienen pequeñas diferencias porque el autor original lo copió y luego solo modificó la copia. Esto es algo grandioso para Evolution, pero no tanto para el código.
  2. Cree una estructura de carpetas racional y mueva todos los archivos en ella. Este es obvio, pero es el que más lamentarás hacer. Si los enlaces en la aplicación son relativos o absolutos, tendrá que cambiar la mayoría de ellos.
  3. Combina todos tus archivos incluidos en un gran archivo. A continuación, puede volver a ordenar todas las funciones lógicamente y dividirlas en archivos separados con nombres sensatos. Luego tendrá que ir a la aplicación página por página y descubrir qué deben contener los enunciados de inclusión en cada página (o quedarse con el único archivo, e incluirlo en cada página; no puedo recordar si esa es una buena idea en ASP). No puedo comprender el nivel de dolor implicado aquí, y eso es suponiendo que los archivos de inclusión existentes no hagan un uso intensivo de los globals del mismo nombre.

No haría nada de esto. Parafraseando a Steve Yegge (creo), "no hay nada malo con una aplicación ASP clásica que no se puede arreglar con una reescritura total de". Lo digo muy en serio: no creo que exista un mayor desperdicio del tiempo de un programador en este mundo que mantener una aplicación ASP, y el problema simplemente empeora a medida que ASP se vuelve cada vez más obsoleto.

+2

Ojalá fuera una opción para mí. :( Desafortunadamente, no tengo muchas opciones. –

+0

Si la aplicación está funcionando (con el nivel de éxito requerido), entonces diría que minimices tu dolor y no cambies nada a menos que sea absolutamente necesario. he hecho esto mucho, y la refactorización de ASP prácticamente no vale la pena. – MusiGenesis

+0

Tengo dos aplicaciones ASP clásicas que escribí hace 10 años y que supuestamente sigo admitiendo. Pero me niego a entrar en el código y hacer mucho. Es un desperdicio Finalmente, la semana pasada recibí la noticia de que están programados para su destrucción en abril. :) – BuddyJoe

0

Creo que deberías considerar mover tu código de ASP VBScript a Visual Basic COM DLLs. eso te facilitará tener demasiado incluye.

+0

¿por qué los votos negativos? Los componentes COM reducirían los includes y proporcionarían una ruta para la migración de .NET. – jwmiller5

+0

Los componentes COM son realmente un dolor para administrar, actualizar, versionar, etc. –

10

@MusiGenisis bala lista de puntos es un buen consejo a seguir, pero me gustaría no están de acuerdo con -

"Porque no quiero hacer nada de esto Parafraseando Steve Yegge (creo)," no hay nada malo con una aplicación ASP clásica que no se puede solucionar con una reescritura total. "Lo digo muy en serio. No creo que haya una pérdida mayor del tiempo de un programador en este mundo que el mantenimiento de una aplicación ASP, y el problema simplemente empeora a medida que ASP se vuelve cada vez más desactualizado ".

Todo muy bien, pero si se trata de una aplicación de legado considerable, la realización de reescrituras completas a menudo no es posible debido a la falta de tiempo/recursos del desarrollador.

Tenemos una aplicación ASP clásica bastante grande que ha crecido brazos y piernas a lo largo de los años, no es bonita, pero sí satisface las necesidades del negocio. No tenemos tiempo para pasar los próximos seis meses haciendo una reescritura completa, sería agradable, pero simplemente imposible. Nuestro enfoque es -

  1. Donde se requiere una nueva funcionalidad, se implementa en ASP.NET. Esto sucede el 95% del tiempo. El 5% de casos extremos suele ser que hay una gran cantidad de puntos donde el nuevo código de la aplicación toca la aplicación anterior, lo que nos obliga a hacer una gran cantidad de trabajos clásicos de ASP para hacer que la aplicación sea más frágil.

  2. Cuando cambia la funcionalidad evaluamos si podemos realizar refactorizaciones en ASP.NET con un impacto mínimo. Si esto no es posible, implementaremos el cambio en ASP clásico y ordenaremos el código existente a medida que avancemos, p. la simplificación incluye la anidación de archivos, reemplazando javascript con más código compatible con navegador cruzado, algo así.

En respuesta a tu pregunta sobre # ifndef's, no hay un equivalente, me temo.

+0

Si está atrapado con eso, creo que su enfoque es perfectamente sensato. – MusiGenesis

+1

+1 Martin Fowler llama a esto una "aplicación de estrangulador". Es pragmático, incremental y ofrece un buen valor para el cliente. http://martinfowler.com/bliki/StranglerApplication.html – MarkJ

+0

@Mark - gracias por el linky, me pregunté si ese enfoque tenía un nombre. – Kev

1

Wow. Me sorprende constantemente la cantidad de gente que odia a ASP. En manos decentes, es un lenguaje perfectamente capaz para diseñar aplicaciones web.

Sin embargo, admitiré que la forma en que se administran los archivos de inclusión en ASP puede ser un poco de una branache, porque (dependiendo de cómo los use) tienen que cargarse y analizarse incluso si no está usando la mitad de las funciones contenidas dentro.

que tienden a tener un archivo de inclusión (initialise.asp o algo así) que sí incluye enlaces a varias bibliotecas de funciones (lib_http.asp, lib_mssql.asp o similares) y todas las funciones de la biblioteca son autónomos por lo que no hay que preocuparse acerca de las variables de cruce. Todos los valores variables globales se declaran y configuran en el archivo maestro. Esto significa que puedo usar una función en cualquier lugar, en cualquier momento y no preocuparme por dónde fue definida, solo está ahí para usarla. Y los IDEs como Visual Studio y Primalscript tienen la capacidad de "saltar a la definición" cuando encuentras una llamada a una función que no reconoces.

Luego, todas las inclusiones específicas del script se incluyen en el script después de que la llamada a este maestro incluye el archivo.

Admito que este es un enfoque que requiere mucha memoria ya que todas las funciones en todas las librerías se compilan para cada llamada de script, por lo que el método necesita ser refinado para cada sitio que desarrolle; decida a qué llamar a través del maestro include y qué es más específico de la página. Sería bueno poder cargar solo lo que necesita, pero ese es el enfoque de DLL y no está disponible para la mayoría de los desarrollos del mundo real, y también tendría que sopesar el costo del procesador de compilar pequeñas secuencias de comandos frente a carga de componentes.

Se necesita una estructura de directorios concisos y fácil de desarrollar, pero puede ser una tarea difícil recorrer todo el código en un sitio existente y cambiar cualquier enlace o llamada de ruta de acceso. Además, tenga en cuenta que algunos administradores de IIS no permiten el método '..\' de recorrer directorios a través de VBScript, por lo que todas las referencias de archivos deben ser rutas absolutas.

3
  1. Utilice un archivo para los títulos globales e incluya (digamos t-head.asp). Este archivo está incluido en todos los archivos asp.
  2. Utilice un archivo para hacer que el encabezado visual global del sitio (logotipos, menús, etc.) lo incluya justo detrás. Deja que lo llame t-begin.asp
  3. Utilice un archivo para hacer que el pie de página visual sea global (copyright, google analytics, etc.) y cierre todos los divs o tablas abiertos en t-begin.asp. Llamemos a este archivo t-end.asp
  4. Use una carpeta para colocar los archivos de lógica de negocios, llamados BUS. Los archivos en esta carpeta no pueden tener inclusiones. Cada función dentro del archivo debe estar precedida por el nombre de la unidad lógica (IE: todas las funciones en products.asp deben comenzar con product_ *)
  5. Use una carpeta para colocar algún código de UI reutilizado llamado UI. Los archivos en esta carpeta no pueden tener inclusiones.

Ejemplo:

<%@ Language=VBScript %> 
<% Option Explicit %> 
<% Response.Buffer = true%> 
<html> 
<head> 
<!--#include file="../general/t-head.asp"--> 
<!--#include file="../bus/product.asp"--> 
<title>Products page</title> 
</head> 
<body> 
<!--#include file="../general/t-begin.asp"--> 

    <% 'all your code %> 

<!--#include file="../general/t-end.asp"--> 
</body> 
</html> 
0

No sé de una manera de evitar una doble inclusión, que no sea un mensaje de error que es. ¿Estás viendo incluye colocado en toda la página, lo que hace que sea difícil de detectar?

Como un lado, ¿está trabajando con una copia del código y la base de datos en un servidor de desarrollo? Desde mi experiencia, lo primero que debe hacer es separarse del sitio en vivo lo antes posible. Si bien inicialmente es una molestia, te dará la libertad de realizar cambios sin estropear el sitio en vivo. ¡Es fácil hacer ese pequeño cambio en un include y BAM! todo el sitio se cae

He trabajado a través de algunos proyectos como el que he descrito y utilizado las siguientes estrategias:

reescritura completa - tiempo/dinero cuando no es perfecto, pero por lo general me da la llamada cuando algo ha ido mal y los resultados son necesarios lo antes posible

Proyectos más pequeños: abro todo en el IDE y simplemente comienzo a buscar todos los archivos del proyecto para las funciones/sub, con el fin de construir un conocimiento de la lógica de inclusión. Casi todo el tiempo, todo se distribuye en todas partes, así que empiezo a reconstruir las inclusiones organizadas por lógica de negocios. También me encontré con un código en línea (código en bruto, no subs o funciones) arrojado a una inclusión, por lo que generalmente voy a volver a introducir el código en la página para refactorizar más adelante.

Proyectos más grandes - Usaré algún código que tenga para analizar las líneas incluidas con encabezados de sub/función y las depositaré en un archivo de texto para crear una lista de las rutinas y referirme a eso. Esto es útil cuando tienes toneladas de inclusiones en cada página y no puedes asimilar la base del código.