¿Cómo organizar el código repetitivo?

Mi equipo crea muchos formularios web únicos. La mayoría de estos formularios solo envían un correo electrónico, y unos pocos escriben una base de datos simple.

En este momento, cada formulario vive en su propia solución separada en Visual Studio Team Foundation Server. Eso significa que tenemos cerca de 100 proyectos de formularios diferentes, lo que hace que sea difícil mantener la coherencia. Cada formulario es único en que los campos son diferentes, pero todos ellos hacen más o menos lo mismo.

Estoy buscando condensarlos de alguna manera, y realmente podría usar alguna guía.

• ¿Debo intentar crear un archivo de solución con todos nuestros proyectos de formulario? No hay mucho código de plomería, aunque podría crear algunas clases auxiliares para ayudar con el formato de correo electrónico y demás. Sería muy útil poder compartir CSS, JavaScript, controles e imágenes entre proyectos.
• Dado que somos una tienda de Microsoft, ¿hay algún beneficio tangible al usar algo como MVC sobre Webforms para este escenario específico? Estoy convencido del concepto de MVC en su conjunto, pero ¿me ayudaría a reunir un formulario de recopilación de datos de 15 campos de manera más eficiente si todo lo que hace es enviar un correo electrónico? El formulario que me hizo pensar en esto tenía una buena lógica incorporada para mostrar y ocultar campos en función de las respuestas del usuario y parece que hubiera sido menos eficiente usar MVC y jQuery.

Re-factorizar de manera segura sin pruebas es difícil y está lleno de peligros.

Yo comenzaría por:

• Escribir caso (s) de prueba que cubren los distintos tipos de entrada en esos formularios y la salida esperada. Parece que esto en realidad no llevaría demasiado tiempo ya que sientes que la mayoría de estas formas son idénticas en funcionalidad o cercanas.

• Ejecute esos casos de prueba contra los aproximadamente 100 formularios (active la cobertura de código para ayudarlo a rastrear las rutas de código).

Después de eso, está en condiciones de ver lo que puede re-factorizar de manera segura, luego puede (un ejemplo):

• Ejecute su herramienta de detección de duplicación de código (no estoy seguro de cómo se llama en .NET, en Java tenemos CPD). Eliminar inmediatamente 13 formas idénticas. Ahora vuelva a ejecutar las pruebas, ¡sí! Todos pasan, excepto el formulario 11, OK, así que no podemos eliminar eso todavía.

• Elimine todo el código de formato de correo electrónico local y obtenga todos los formularios para llamar a un módulo de procesamiento de correo electrónico común. Ejecute pruebas, todas pasan, excepto una, hhmmm OK ... UTF-8 caracteres, arregle eso en el módulo genérico, ejecute pruebas nuevamente, ¡sí, todos estamos bien!

enjuague y repita.

Sugeriría resumir la parte de envío. Usando Modelo / Vista / Controlador, coloque los formularios en la Vista y haga que usen el mismo controlador. Este controlador puede realizar una acción genérica, como enviar un correo electrónico a una dirección predeterminada, o desviar los datos del formulario a un controlador que pueda. De esa manera, todo lo que tiene que hacer para crear un nuevo formulario es crear el formulario y dirigir la salida a ese controlador. Esta arquitectura podría estar contenida en un solo proyecto, lo que le permitiría compartir CSS y JavaScript como usted mencionó.

Para manejar el formateo de los correos electrónicos, comenzaría creando un formateador genérico, digamos uno que solo enumere los nombres y valores de los elementos del formulario, así como el otro tipo de metadatos como el tiempo enviado, etc. Puede hacer esto tan elegante como desee . Luego, si realmente necesita un manejo más personalizado que eso, agregue una fábrica. La fábrica devolvería una interfaz de formateador. Luego, dentro de la fábrica, puede buscar un formateador para ese formulario específico o devolver el genérico si no existe uno específico. Este diseño también facilitaría las pruebas unitarias del controlador, ya que podría suministrar fácilmente un formateador simulado para fines de prueba.

Por cierto, no pondría la dirección de correo electrónico como un argumento del formulario. Si necesita enviar a varias direcciones, le sugiero que tenga una tabla de búsqueda que contenga todos los formularios y el correo electrónico para enviarlos. Esto podría implementarse en XML o en código (he visto ambos, aunque no estoy seguro de si alguno es mejor). Esto ayudará a evitar que los spammers obtengan sus direcciones de correo electrónico desde la página del formulario.