No un_tio, no me refería a que tu código se vea bonito o no, por diseño me refiero a los flujos de datos de tu sistema, lo que quise decir con un buen diseño, es precisamente lo contrario a lo que apuntas aquí:
Cita: Lo que es innegable es que a más líneas de código, por bien estructuradas que estén, más dificultad habrá para seguir por dónde van los RecordSet u otros objetos
En realidad un código bien estructurado no tiene por qué invitar a confusiones de este tipo, se trata nada mas de controlar las entradas/salidas de tu aplicación.
Código:
Function ObtenerLoqueQuieras()
'abres tus objetos
'haces tus procedimientos
'Cierras y destruyes tus objetos utilizados para este procedimiento
'quiero regresar un arreglo a partir de un recordset
End Function
llamo a mi funcion, que me regresa un arreglo
codigo HTML
imprimo mi arreglo, si quiero lo puedo mezclar ahora si con el HTML, pues solo son datos
Esa(s) funciones, las podrías tener en un include, y mejor si las encapsulas en una clase, así trabajas con un objeto
Código:
Set miObjeto = new Objeto
llamas a todos los procedimientos que quieras
codigo HTML
imprimes resultados
destruyes objeto
En este simple ejemplo, podemos ver un código limpio, no hay razón para extraviar procedimientos...
Desgraciadamente en ASP tradicional, es un poco más complicado o mejor dicho es bastante sencillo mezclar el diseño gráfico de la lógica de tu aplicación, esto me imagino por la flexibilidad que tiene esta plataforma y quizás por algunos problemas de arquitectura, y por malas costumbres de nosotros como desarrolladores que no entendimos los mejores usos de esta plataforma.
Con el tiempo surgieron alternativas para subsanar estos "problemas" como la incorporación de XML - XSL para separar la capa lógica de nuestra presentación.
Finalmente, si programas de una manera limpia, no crearás telarañas que al final no podrás desenrredar ni tu mismo, no hablemos de que venga o otra persona a tratar de hacerlo, espero que nunca te pase que "algún genio" haga una telaraña y abandone el proyecto y llegues tú al rescate...y taráaaannnn, te encuentras con que ese código no tiene ni piés ni cabeza, al final decidirás escribir uno nuevo.
Solamente para responder a la pregunta inicial, dicen los que saben que "aparentemente" al terminar la ejecución de un script, el IIS destruirá todos los objetos que no se encuentren destruidos, pero según no es verdad, así que si no lo haces por costumbre, tu aplicación tendrá una carga extra por todos esos objetos que solo porque no se te antojó revisar tu código no cerraste.
Salu2,