No puedo estar más de acuerdo! No obstante, cuando se dan esos escenarios y tenemos que lidiar con portales sometidos a un alto número de visitas o con altos ratios de actualización, es altamente recomendable recurrir a la ayuda de herramientas especializadas que proporcionen los mecanismos de caché, publicación, actualización del portal, etc. adecuados al rendimiento requerido por el cliente y sus usuarios.

Un saludo!

Ciertamente el termino “interpretado” no ha sido el más acertado jeje.

Es cierto que aspnet realiza un compilado de las páginas la primera vez que se realiza una petición, quedando una clase compilada del estilo default.aspx.cdcab7d2.compiled.

Sin embargo, en ciertos casos, nuestra experiencia nos dice que esto no es recomendable, por ejemplo, para portales con un gran número de páginas y controles (se generan y cargan un gran numero de dlls y el rendimiento cae), o en portales con alto ratio de actualización en las paginas y controles; en estos casos hemos comprobado que forzar la no compilación del aspx favorece el rendimiento, pero si el aspx no esta compilado el rendimiento se ve afectado si tienes código de servidor en la página o control.

Así pues hemos optado por adoptar como buena práctica reducir al máximo el código de servidor dentro de las páginas y controles.

Aunque es cierto que el objetivo fundamental de no utilizar código de servidor en páginas o controles es la separación lógica/presentación.

Respecto a MVC Framework, prometo ponerme al día sobre él en cuanto tenga un ratejo de relax.

Y abro un thread de discusión sobre el y comentamos sus bondades y maldades jejeje.

Un saludo!

En base al contenido del fichero .aspx se genera un fichero de código que se compila y se ejecuta. El resultado de esta operación puede ser consultado en la carpeta “Temporary ASP.NET Files”.

Es cierto que la inclusión se código de servidor dentro de los ficheros .aspx en lugar de recurrir a la clase trasera de la página (.aspx.cs) se ha considerado una mala praxis desde la aparición del modelo de Web Forms propuesto por Microsoft en ASP.Net. Aunque desde un punto de vista purista, todo aquello que esté entre “” se considera código de servidor, independientemente de si se trata de un contexto de databinding o no.

El principal objetivo de esta regla es básicamente separar las capas de lógica de negocio de la presentación, algo que desde la aparición de ASP.Net MVC se puede enfocar desde otra manera. Sin posicionarme ni a favor ni en contra de ninguno de los dos modelo (ASP.Net MVC vs Web Forms), resulta curioso cómo lo que en un modelo se considera una mala praxis, en el otro es una práctica habitual debido a que establece otros mecanismos de separación de la lógica de negocio y la presentación.