El éxito de las aplicaciones ASP generalmente depende de la compensación entre la arquitectura y el diseño. Teniendo en cuenta la amplia gama de tecnología ASP y la complejidad inherente de las aplicaciones actuales, esta compensación es muy difícil. Aquí hay una breve introducción a los principios y el uso de ASP en el nuevo canal de tecnología incorrecto.
Establecer convenciones de nomenclatura y estandarizar la estructura del directorio puede ayudarlo a mejorar en gran medida la legibilidad y mantenimiento de sus aplicaciones ASP. Aunque actualmente no hay estándares formales para aplicaciones ASP, muchos desarrolladores han establecido algunas formas comunes. Aquí, compartiré con ustedes algunas formas más generales.
Debido a que la tecnología ASP se basa en que los motores de script funcionen, y los guiones tienen la naturaleza de no ser estricto de tipo, las convenciones de nombres también son vagas. En idiomas con tipos muy estrictos, las variables se declararán de acuerdo con su tipo real. Al usar la tecnología ASP, las variables generalmente se declaran en el código ASP en la forma en que procesan las variables, en lugar de su tipo de datos real. Por ejemplo, cuando se usa "Visual Basic (R) Scripting Edition (VBScript)", aunque todas las variables VBScript son variantes, declara el indicador de éxito como Bsuccess (B para Boolean) en lugar de VSuccess (V para variantes).
La siguiente tabla son algunas convenciones de nombres comunes.
Prefijo variable:
| Prefijo | Variables utilizadas | Ejemplo variable |
|---|---|---|
| b o bln | Booleano | bsuccess |
| c o curs | Divisa | mono |
| d o dbl | Doble | dBlquantidad |
| dt o dat | Fecha y hora | dtdate |
| F o FLT | Flotar | fratio |
| L o GNG | Largo | lmillisegunds |
| I o int | Entero | idounter |
| s o str | Cadena | sname |
| a o arr | Formación | ausers () |
| o u obj | COM Objeto | aparato |
Prefijo variable para objetos de base de datos:
| Prefijo | Variables utilizadas | Ejemplo variable |
|---|---|---|
| CNN | Conexión | cnnpubs |
| primero | Conjunto de registros | rsstauthors |
| CMD | Dominio | cmdemployee |
| FLD | Campo | nombre de nombre |
Uso de rango y prefijo:
| Prefijo | ilustrar |
|---|---|
| gramo_ | Creado en Global.asa. |
| metro_ | Para páginas ASP o en archivos de incluido, es local. |
| (Sin prefijo) | Variables no estáticas, los prefijos son locales para el proceso |
Una publicación en la base de conocimiento (KB) "Q110264 Información: Microsoft Consulting Services Naming Convencions for Visual Basic" (en inglés) proporciona información sobre las convenciones de nombres.
Use estructuras de directorio cuando sea posible para proporcionar una ubicación consistente para sus diversos componentes de aplicación. La estructura real del directorio de su aplicación, por supuesto, depende de usted, pero generalmente es para colocar imágenes, documentos, incluir archivos y componentes en directorios separados. El siguiente es un ejemplo de una estructura simple de directorio de aplicaciones ASP.
Ejemplo de estructura del directorio:
/SimpleAspapp /Docs /Images /Incluye
Una buena estructura de directorio le permite aplicar selectivamente los permisos de NTFS. También puede usar rutas relativas desde una aplicación ASP. Por ejemplo, puede usar el siguiente código para hacer referencia al archivo de inclusión Top.asp en el directorio de INCLUSIÓN desde la página predeterminada.asp ubicada en el directorio de SimpleAspapp:
./includes/top.asp
Tenga en cuenta que la extensión de mi archivo de incluido es .asp, no .inc. Esto se hace por razones de seguridad, y utiliza la extensión .asp (en lugar de .inc), y también permite la codificación de color en Visual Interdev (R).
Para obtener algunos otros consejos y consejos sobre aplicaciones ASP estructuradas, consulte el artículo "Convenciones ASP" (en inglés).
El ASP se ejecutará bajo el servicio. Al diseñar una aplicación ASP, inmediatamente enfrentará entornos de seguridad y problemas de enhebrado que no encontrará en su aplicación de escritorio. En un entorno de escritorio, solo la ejecución de un solo subproceso se ejecuta como usuario interactivo generalmente se maneja y tiene acceso al sistema de escritorio actual. En Internet Information Services (IIS), se simulan múltiples hilos de clientes en diferentes entornos de usuario para llamar a su aplicación, y su aplicación se limita al escritorio "Sistema".
¿Qué significa esto para ti? Aprenda el modo de seguridad de IIS. También recuerde: el hecho de que algo pueda funcionar correctamente bajo el IDE Visual Basic no significa que pueda ejecutarse de manera segura en la tecnología ASP. Visual Basic IDE no simula con precisión el entorno de tiempo de ejecución. Los errores de diseño comunes incluyen el uso de controles .OCX que requieren interfaces de usuario en la tecnología ASP, el uso de componentes que no son seguros para los subprocesos y el uso de componentes que requieren contextos de usuario especiales. Uno de los problemas más fáciles de evitar es tratar de acceder a la clave del registro HKEY_CURRENT_USER (HKCU) de la aplicación (por ejemplo, no llame a las funciones de Getting y Gettinginginging de Visual Basic, las cuales dependen de HKCU). Del mismo modo, no aparezcan cuadros de mensaje u otros cuadros de diálogo que requieren que el usuario interactúe con la computadora humana.
Los siguientes artículos son libros introductorios bastante buenos sobre problemas de seguridad y verificación en tecnología ASP:
La tecnología ASP proporciona un servicio de representación al generar salida HTML. En resumen, genera una interfaz de usuario. Debe separar la lógica comercial del script de representación ASP. Incluso si no utiliza los componentes COM para separar la lógica comercial del código ASP, al menos separar la lógica comercial en funciones e incluir archivos para mejorar la mantenimiento, la legibilidad y la reutilización. También puede apreciar los beneficios de los métodos de diseño modular cuando se necesitan problemas de solución de problemas y aislamiento.
Llamar a las funciones y métodos dentro del script puede evitar estropear el código y agregar estructuras a aplicaciones ASP. El siguiente ejemplo muestra cómo separar la lógica en las llamadas de método del código ASP:
lt;% main () myBizMethod () ... sub main () getData () displayData () final sub%>
Este principio se puede aplicar al usar técnicas que incluyen la funcionalidad ASP. Aquí hay un ejemplo de cómo usar este principio cuando se usa Visual Basic Webclass:
Un problema común es la transición del sistema de escritorio al servidor. Muchos desarrolladores con fondo de sistemas de escritorio nunca han estado preocupados por algunos problemas de servidor y compartir recursos. En las aplicaciones de escritorio tradicionales, conectarse a un servidor es un proceso que requiere mucho tiempo. Para mejorar la experiencia del usuario, generalmente se usa para adquirir recursos temprano y retrasar la liberación de recursos. Por ejemplo, muchas aplicaciones siempre se conectarán a la base de datos durante su tiempo de ejecución.
Este método funciona correctamente en aplicaciones de escritorio tradicionales. La razón es que el número de usuarios es muy claro, fácil de controlar, y el backend y el frontend están estrechamente conectados. Sin embargo, para las aplicaciones web actuales, este enfoque ya no es factible porque los recursos limitados del servidor enfrentarán más y más usuarios. Para que su aplicación haga frente al aumento de los usuarios, debe obtener recursos lo más tarde posible y liberar recursos lo antes posible.
Compartir ayuda a aumentar la efectividad de este enfoque. A través del intercambio, varios usuarios pueden compartir recursos, con el tiempo de espera mínimo y el impacto mínimo en el servidor. Por ejemplo, cuando se trabaja con una base de datos, el intercambio de conexión ODBC y el intercambio de recursos OLEDB pueden habilitar la selección de conexiones desde un grupo compartido, minimizando la sobrecarga de conectarse a la base de datos.
Para obtener más información sobre cómo compartir ADO, consulte "Agrupación en componentes de acceso a datos de Microsoft".
Aunque el protocolo HTTP es apátrido, los desarrolladores de ASP a menudo usan el mecanismo de retención del estado integrado en funciones ASP. Por ejemplo, utilizando el objeto de aplicación integrado en la tecnología ASP, todos los usuarios de la aplicación pueden compartir los recursos guardados por los desarrolladores. Al usar los objetos de sesión incorporados de ASP, los desarrolladores guardan recursos solo para un solo usuario.
Aunque parece que guardar información en un objeto de sesión de tecnología ASP es una forma muy conveniente de mantener el estado, este enfoque es demasiado costoso y también puede ser uno de los factores limitantes más limitantes sobre la escalabilidad. La escalabilidad de una aplicación es esencialmente la capacidad de continuar manteniendo su rendimiento a medida que aumenta el número de usuarios. Para cada usuario, el objeto de sesión consume los recursos del servidor antes de que la sesión se agotara o fuera abandonada. Las sesiones también lo vinculan a un servidor, limitando su capacidad para aprovechar el clúster web. No use objetos de sesión ASP para la administración estatal tanto como sea posible. Si no está utilizando una sesión en absoluto, puede deshabilitar el estado de la sesión de su aplicación web (consulte la documentación IIS). De lo contrario, puede deshabilitar el estado de la sesión para cada página utilizando la siguiente declaración:
< %@HabilsessionState = falso %>
Para algunos datos simples, puede usar la cookie de consulta o un dominio de formulario oculto para mantener el estado entre las solicitudes ASP. Luego, para obtener información más compleja, generalmente se recomienda que use una base de datos. El enfoque general es generar un identificador único, luego enviarlo a cada cliente solicitante y guardarlo como un campo de formulario oculto. En solicitudes posteriores, este identificador único se utiliza para buscar información de estado relacionada con el usuario en la base de datos. Este enfoque proporciona una mayor escalabilidad y un código más conciso y claro.
Para obtener más información sobre el uso de cookies de consulta y campos de formularios ocultos, consulte "Q175167 Howto: Valores persistentes sin sesiones".
Al crear un objeto de tecnología ASP, puede elegir
Aquí hay una posible excepción: cuando realiza una llamada a través de un firewall, es posible que deba llamar a CreateObject en lugar de server.CreateObject . Para obtener más información, consulte "Q193230 - PRB: Server.CreateObject falla cuando el objeto está detrás del firewall" (inglés).
Asegúrese de que el manejo de errores esté incluido en todas sus aplicaciones ASP. Y asegúrese de proporcionar información de diagnóstico útil. No me he encontrado con nadie que se queje de que el mensaje de error es demasiado explicativo. Asegúrese de incluir la siguiente información en el registro de errores:
Debido a que se ejecutará en ASP, es posible que desee escribir esta información en un archivo o el registro de eventos de NT. También puede crear registros de eventos de aplicación que registren eventos críticos de la aplicación para su uso al diagnosticar errores de aplicación.
El siguiente artículo proporciona información detallada sobre las técnicas de manejo de errores:
Un navegador no es la forma exacta de probarlo, solo puede mostrarle los posibles usos de la aplicación. Establezca objetivos de rendimiento específicos para su aplicación y use herramientas de carga como la herramienta de estrés de aplicación web para pruebas de estrés. Debe decidir por sí mismo qué puede aceptar su entorno, y aquí hay algunas pautas comunes para ayudarlo a comenzar su proceso de prueba:
Haga coincidir el entorno de prueba con el entorno de ejecución real, e incluso el firewall no es una excepción. Esto suena costoso, pero he escuchado a los desarrolladores perder sus trabajos porque no tienen en cuenta el firewall.
Para obtener más información sobre cómo probar una aplicación ASP utilizando la herramienta de estrés de aplicación web, consulte "No puedo estresarlo lo suficiente: cargue pruebe su aplicación ASP".
Proteger su proceso de aplicación con aislamiento puede mejorar en gran medida la estabilidad del servidor. Cuando se trata de aplicaciones de Internet, las consecuencias del uso de aislamiento pueden variar mucho: una es el bloqueo de la aplicación y el otro es el bloqueo del servidor. Proteger el proceso IIS primario (inetinfo.exe) generalmente se encuentra en una lista de prioridades más altas. Esto es particularmente prominente cuando usa componentes.
La técnica comúnmente utilizada para proteger el proceso de ISS principal es permitir que las aplicaciones web se ejecuten en sus respectivos espacios de memoria. En Internet Services Manager, puede establecer esta opción para cada web. Aunque los recursos del sistema que están abrumados por los procesos de ensarchamiento tendrán un ligero impacto en el rendimiento, el efecto de protección en las aplicaciones vale el costo. Bajo IIS 4.0, puede ejecutar su aplicación en proceso y fuera de proceso (OOP). La aplicación OOP se ejecuta en la nueva instancia MTX.EXE. Bajo IIS 5.0, puede usar otras opciones de aislamiento. El nivel de aislamiento se puede establecer en "baja" (aplicación en proceso para inetinfo.exe), "medio" (instancia compartida dllhost.exe) o "alta" (instancia no shared de dllhost.exe).
Además de aislar aplicaciones web en su propio espacio de memoria, también es posible que desee aislar componentes no confiables. Los componentes en los que no se confía generalmente son componentes que no pasan el tiempo de prueba en el entorno real. Puede ejecutar estos componentes en el paquete del servidor para que se ejecuten en la nueva instancia dllhost.exe.
En términos generales, si desea adoptar un enfoque moderado entre el rendimiento y la protección, lo siguiente es el camino: ejecute la aplicación web en un estado de aislamiento "alto" y ejecute los componentes en el paquete de la biblioteca. Este enfoque minimiza los gastos de ensarca al tiempo que proporciona la mayor protección entre los procesos.
Para obtener más información, consulte el artículo "Confiabilidad del servidor a través del aislamiento del proceso".
Bajo IIS 4.0, el grupo común predeterminado de ASP es de 10 hilos para cada procesador administrado por MTS. En IIS 5.0, el valor predeterminado es 20. Esto significa que cada hilo es un recurso potencialmente valioso que puede manejar múltiples solicitudes de clientes. También debe evitar los métodos de bloqueo que puedan ocurrir, como hacer grandes llamadas de base de datos. Si tiene un trabajo para hacer esto, evitará que la aplicación ASP devuelva la respuesta al cliente rápidamente, considere usar la función de cola. Por ejemplo, en NT 4.0, se puede usar MSMQ. En Windows 2000, se pueden usar componentes en cola.
Un inconveniente común de no almacenar componentes de apartamento de un solo subpuesto (STA) en la sesión es que llenan los objetos Visual Basic en el alcance de la sesión. Bloqueará al usuario en un hilo, que se ejecutará en contra del propósito de compartir un grupo por hilos. Los usuarios potenciales serán bloqueados detrás de otros usuarios, esperando que los hilos que creen sus componentes se vuelvan válidos. Debe usar otras formas de diseñar componentes sin estado que se puedan crear y destruir en función de cada página.
Consejos rápidos: asegúrese de que la función de depuración de script ASP esté deshabilitada en el servidor (usando Internet Services Manager). Si la depuración del script ASP está habilitada, la ejecución de ASP se bloqueará en un hilo.
Para obtener más información, consulte el siguiente artículo:
La creación de una aplicación ASP requiere una gama considerable de conocimiento. Un desafío para las aplicaciones ASP es que actualmente no hay reglas comunes (que también es parte de la diversión). Otro problema es que muchos desarrolladores han participado en el desarrollo del sistema de escritorio antes de entrar en contacto con el desarrollo de Internet. Al aplicar las reglas anteriores en sus esfuerzos de desarrollo de ASP, tiene la esperanza de evitar errores costosos y poder desarrollar aplicaciones ASP bastante buenas.
JD Meier nació y creció en la costa este de los Estados Unidos. Después del consejo de Horace Greeley, se convirtió en ingeniero de soporte para desarrolladores, centrándose en componentes del lado del servidor, incluidas las tecnologías MTS y ASP, así como las aplicaciones de ADN de Windows.
A través del contenido introducido por el editor del 未分 New Technology Channel, creo que todos tienen un cierto entendimiento. Si desea saber más contenido técnico, ¡continúe prestando atención al 未分 未分 nuevo canal de tecnología!