¿Diseñando todas las páginas completamente en el código subyacente?

Question

Nuestro portal web actual en el trabajo era un puerto de una base de código ASP clásico. Actualmente, todas las páginas de nuestro proyecto extienden una clase personalizada Page llamada PortalPage. Maneja el inicio/cierre de sesión, proporciona acceso a un objeto público User para el usuario autenticado actualmente, y agrega el encabezado y el pie de página estándar a todas nuestras páginas.

Cada La página en nuestro sitio está 100% diseñada en el código subyacente. La página ASPX no se usa en absoluto. Cada div, img y bloque de texto se asignan como un objeto y se agregan desde una función C#, incluso si se trata de contenido completamente estático (del que tenemos una cantidad decente).

Ejemplo para un encabezado de página:

HtmlGenericControl wrapperDiv = new HtmlGeneric("div"); 
HtmlAnchor bannerLink = new HtmlAnchor(); 
HtmlImage banner = new HtmlImage(); 

bannerLink.HRef = "index.aspx"; 
banner.Src = "mybanner.png"; 
banner.Alt = "My Site"; 

bannerLink.Controls.Add(banner); 
wrapperDiv.Controls.Add(bannerLink); 
this.Page.Controls.Add(wrapperDiv); 

Lo que es peor, se añade todo el Javascript para la página como un lío gigante de concatenaciones de cadenas:

ClientScript.RegisterClientScriptBlock(this.GetType(), "javascript", @" 
    <script language='javascript'> 
     fullUrl = '" + ConfigurationManager.AppSettings["fullUrl"].ToString() + @"'; 
     function showModule() 
     { 
      $('#" + this.userModule.ClientID + @"').css('display','block'); 
      $('#" + this.groupModule.ClientID + @"').css('display','none'); 
      $('#" + this.listsModule.ClientID + @"').css('display','none'); 
      $('#" + this.labelsModule.ClientID + @"').css('display','none'); 
     } 

En la actualidad, uno de mis compañeros de trabajo aducen que asignar cada objeto en el código subyacente es cientos de veces más rápido que utilizar el enfoque ASPX w/Codebehind que veo en todas las demás aplicaciones web. Esto va en contra de mis instintos, ya que básicamente está agregando runat="server" a cada pieza de HTML en la página.

También dice que todas las tiendas profesionales escriben el código de esta manera y nunca usan páginas ASPX. Él dice que todos los libros de texto y el código de muestra utilizan páginas ASPX porque son más fáciles de entender para los programadores novatos. ¿Hay algo de cierto en esto o solo estamos escribiendo de una manera increíblemente ineficiente por el bien de la tradición?

Para que podamos cambiar a la forma "estándar" de escribir formularios web, necesito proporcionar alguna fuente para mostrar que está equivocado.

Mi problema es que nunca he oído hablar de nadie escribiendo todo en el código subyacente. Todos los ejemplos que he visto páginas ASPX utiliza para la interfaz de usuario y un código subyacente de la lógica, las llamadas bases de datos, etc.

Así que en resumen:
1) ¿Son las páginas ASPX realmente mucho más lento que el 100% de código subyacente?
2) ¿Las tiendas profesionales realmente usan código 100% detrás?
3) Si ASPX w/codebehind es el camino a seguir, ¿alguien tiene enlaces válidos que puedan ayudarme a respaldarme?

Answer 1

1. Todos se compilan en ensamblajes. El .aspx se carga una vez al inicio de la aplicación y se analiza una vez.
2. No, no si tienen algún sentido.
3. Mire cada libro en el sitio web sobre ASP.NET. Ellos todos usan .aspx.

Una forma de probar esto es ejecutar una prueba de rendimiento, con dos páginas .aspx que son completamente idénticas. Además de un posible retraso de inicio corto para el .aspx (análisis y compilación), dudo que se detecte una diferencia significativa.

Usando todo el código detrás es una manera de perder la oportunidad de:

• Trabajar con diseñadores que entienden HTML
• poder inspeccionar visualmente el marcado
• Ser capaz de cambiar fácilmente diseños
• Obtener desarrolladores experimentados de asp.net para trabajar con usted ...
• Tener una manera sensata de desarrollar asp.net
• gran utillaje e integración existentes

Answer 2

Su compañero de trabajo es absolutamente, terriblemente , mal.

Answer 3

Ni siquiera sé por dónde empezar con esto.

No puedo hablar de las inquietudes sobre el rendimiento, pero he trabajado en docenas y docenas de aplicaciones de WebForms, y ni una sola tenía un problema donde el cuello de botella de rendimiento tenía que ver con el uso de la página aspx.

Esto suena como una pesadilla completa.

1. Presentación cosas van en el aspx.

2. Los controladores de eventos van en el código subyacente

3. La lógica de negocio va en una clase separada por completo.

4. amigo es , y los archivos js separados son allí para que pueda mantener su cordura .

Answer 4

No habrá demasiadas diferencias significativas si lo ejecuta en niveles de casos pequeños. Así que probarlo con una página pequeña es algo difícil de hacer. Encontrará diferencias de rendimiento con casos de uso más complejos (como con su portal).

Si bien entiendo que está utilizando WebForms, eche un vistazo a ASP.NET MVC, o CUALQUIER marco de MVC para el caso, como guía.

1. Cualquier cosa que se genera como una vista entra en la página ASPX
2. Cualquier cosa que dicta lo que se pone en la vista (el controlador) se pone en el código detrás
3. Cualquier cosa que se utiliza para representar lo entrará en la vista está en su clase.
4. Todo lo que debe ser la presentación general de su sitio debe ir en una página maestra.

Cuando haces todo lo que está en el código subyacente (JavaScript incluido) pierdes algo más que problemas de rendimiento con la RAM/CPU. Pierde su tiempo personal, ya que tiene que compilar todas y cada una de las veces que desee actualizar la interfaz de usuario o la secuencia de comandos del lado del cliente de su sitio web. Entonces también tiene que meterse con los archivos DLL en su servidor, en lugar de simplemente con la página ASPX.

El tiempo es dinero, amigo.