Consejos para evitar una gran bola de barro con ASP.NET WebForms

Question

Aunque ASP.NET MVC parece tener todo el revuelo estos días, los WebForms siguen siendo bastante omnipresentes.¿Cómo mantienes tu proyecto cuerdo?Recopilemos algunos consejos aquí.

Answer 1

• Cree controles de usuario web para cualquier cosa que se mostrará en más de una página que no forme parte del contenido de tipo página maestra.Ejemplo:Si su aplicación muestra información del producto en 10 páginas, es mejor tener un control de usuario que se use en 10 páginas en lugar de cortar y pegar el código de visualización 10 veces.
• Coloque la menor lógica de negocios posible en el código subyacente.El código subyacente debe remitirse a su capa empresarial para realizar el trabajo que no está directamente relacionado con colocar cosas en la página y enviar datos de un lado a otro desde la capa empresarial.
• No reinventes la rueda.Muchos de los códigos subyacentes descuidados que he visto se componen de código que hace cosas que el marco ya proporciona.
• En general, evite los bloques de script en el HTML.
• No dejes que una página haga demasiadas cosas.Algo que he visto una y otra vez es una página que dice que tiene modos de agregar y editar.Está bien.Sin embargo, si tiene muchos submodos para agregar y editar, es mejor tener varias páginas para cada submodo con reutilización a través de controles de usuario.Realmente debes evitar utilizar un montón de IF anidados para determinar qué está tratando de hacer tu usuario y luego mostrar las cosas correctas dependiendo de eso.Las cosas se salen de control rápidamente si su página tiene muchos estados posibles.
• Aprenda/asimile el ciclo de vida de la página y utilícelo a su favor.Muchas páginas feas con código subyacente que he visto podrían ser más limpias si el codificador entendiera mejor el ciclo de vida de la página.

Answer 2

Generalmente trato de mantenerme alejado de eso...pero cuando uso WebForms, sigo estos preceptos:

1. Mantenga limpio el HTML resultante:Sólo porque no estás codificando manualmente cada <div> no significa que el código generado tenga que convertirse en una pesadilla ilegible.Evitar controles que produzcan código feo puede resultar rentable al reducir el tiempo de depuración más adelante, al hacer que los problemas sean más fáciles de ver.
2. Minimizar las dependencias externas:No le pagan por depurar el código de otras personas.Si usted hacer Elija confiar en componentes de terceros y luego obtenga la fuente para no tener que perder mucho tiempo solucionando sus errores.
3. Evite hacer demasiado en una página:Si se encuentra implementando "modos" complejos para una página determinada, considere dividirla en varias páginas de modo único, tal vez usando páginas maestras para factorizar aspectos comunes.
4. evitar la devolución de datos:Esta siempre fue una idea terrible y no se ha vuelto menos terrible.Los dolores de cabeza que se ahorrará al no utilizar controles que dependen de la devolución de datos son una buena ventaja.
5. Evite el ESTADO DE VISTA:Ver comentarios para el n.° 4.

Answer 3

Con proyectos grandes, la mejor sugerencia que puedo darle es seguir un patrón de diseño común en el que todos sus desarrolladores estén bien capacitados y sean conscientes.Si trabaja con ASP.NET, las dos mejores opciones para mí son:

o Presentador de vista de modelo (aunque ahora esto es Controlador Supervisor y Vista Pasiva).Este es un modelo sólido que impulsa la separación entre su interfaz de usuario y su modelo de negocio que todos sus desarrolladores pueden seguir sin demasiados problemas.El código resultante es mucho más comprobable y mantenible.El problema es que no se aplica y es necesario escribir mucho código de soporte para implementar el modelo.

o ASP.NET MVC El problema con este es que está en la vista previa.Hablé con Tatham Oddie y mencioné que es muy estable y utilizable.Me gusta, impone la separación de preocupaciones y lo hace con un mínimo de código adicional para el desarrollador.

Creo que sea cual sea el modelo que elijas, lo más importante es tener un modelo y asegurarte de que todos tus desarrolladores puedan ceñirse a ese modelo.

Answer 4

Comience con las páginas maestras el día 1: es complicado volver a actualizarlas.

Answer 5

Siguiendo lo que dijo Odd, estoy probando una versión de MVP llamada Model Presentation que me está funcionando bien hasta ahora.Todavía lo estoy entendiendo y adaptándolo a mi propio uso, pero es una actualización del código que solía escribir.

Compruébalo aquí: Modelo de presentación

Answer 6

Utilice el control de versiones y una estructura de carpetas para evitar que haya demasiados archivos en la misma carpeta.No hay nada más doloroso que esperar a que el Explorador de Windows cargue algo porque hay más de 1000 archivos en una carpeta y tiene que cargarlos todos cuando se abre la carpeta.También es bueno tener una convención sobre el nombre de variables y métodos por adelantado, si es posible, para que no haya esta mezcolanza de códigos en los que diferentes desarrolladores ponen sus toques únicos y se nota dolorosamente.

El uso de patrones de diseño puede ser útil para organizar el código y escalarlo bien, p.un patrón de estrategia puede hacer que sea más fácil agregar un nuevo tipo de producto o dispositivo que deba ser compatible.Similar al uso de algunos adaptadores o patrones de fachada.

Por último, sepa qué estándares mantendrán sus formularios:¿Es solo para usuarios de IE o cualquiera de IE, Firefox o Safari debería cargar fácilmente el formulario y verse bien?