Como organizar o código repetitivo?

Minha equipe cria muitos formulários da web únicos. A maioria desses formulários apenas envia um e-mail, e alguns escrevem um banco de dados simples.

No momento, cada formulário reside em sua própria solução separada no Visual Studio Team Foundation Server. Isso significa que temos quase 100 projetos de formulários diferentes, o que dificulta a manutenção da consistência. Cada formulário é único, pois os campos são diferentes, mas todos fazem praticamente a mesma coisa.

Estou procurando condensá-los de alguma forma e realmente posso usar alguma orientação.

• Devo tentar criar um arquivo de solução com todos os nossos projetos de formulário? Não há muito código de canalização, embora eu possa criar algumas classes auxiliares para ajudar na formatação de e-mail e tal. Seria muito útil poder compartilhar CSS, JavaScript, controles e imagens entre projetos.
• Dado que somos uma loja da Microsoft, existem benefícios tangíveis em usar algo como MVC sobre Webforms para esse cenário específico? Sou vendido sob o conceito de MVC como um todo, mas isso me ajudaria a reunir um formulário de coleta de dados de 15 campos com mais eficiência se tudo o que esse formulário fizer for enviar um email? O formulário que me levou a pensar nisso tinha uma boa lógica embutida para mostrar e ocultar campos com base nas respostas do usuário e parece que teria sido menos eficiente usar MVC e jQuery.

Re-fatorar com segurança sem testes é difícil e cheio de perigos.

Eu começaria por:

• Gravação de casos de teste que abrangem os vários tipos de entrada nesses formulários e a saída esperada. Parece que isso não levaria muito tempo, pois você acha que a maioria dessas formas é idêntica em funcionalidade ou próxima a ela.

• Execute esses casos de teste nos mais de 100 formulários (ative a cobertura do código para ajudá-lo a rastrear caminhos de código).

Depois que você estiver em uma posição para ver o que você pode redimensionar com segurança, você poderá (um exemplo):

• Execute sua ferramenta de detecção de duplicação de código (não sabe como é chamado no .NET, em Java, temos CPD). Remova imediatamente 13 formas idênticas. Agora execute novamente os testes - Yay! Todos são aprovados, exceto o formulário 11, OK, por isso não podemos excluí-lo ainda.

• Remova todo o código de formatação de email local e obtenha todos os formulários para chamar um módulo de processamento de email comum. Execute testes, todos eles passam, exceto um, hhmmm OK ... Caracteres UTF-8, corrija isso no módulo genérico, execute testes novamente, sim, estamos todos bem!

enxague e repita.

Sugiro abstrair a parte de envio. Usando Model / View / Controller, coloque os formulários na View e faça com que eles usem o mesmo controlador. Esse controlador pode executar uma ação genérica, como enviar um email para um endereço padrão ou desviar os dados do formulário para um controlador que possa. Dessa forma, tudo o que você precisa fazer para criar um novo formulário é criar o formulário e direcionar a saída para esse controlador. Essa arquitetura poderia estar contida em um único projeto, o que permitiria compartilhar CSS e javascript conforme mencionado.

Para lidar com a formatação dos e-mails, eu começaria criando um formatador genérico, digamos um que apenas liste os nomes e valores do elemento do formulário, bem como o outro tipo de metdados, como o tempo enviado, etc. Você pode fazer isso da maneira que desejar . Então, se você realmente precisar de mais tratamento personalizado do que isso, adicione uma fábrica. A fábrica retornaria uma interface do formatador. Em seguida, dentro da fábrica, você pode procurar um formatador para esse formulário específico ou retornar o genérico se não houver um específico. Esse design também facilitaria o teste de unidade do controlador, uma vez que você poderia fornecer facilmente um formatador simulado para fins de teste.

Aliás, eu não colocaria o endereço de email como argumento no formulário. Se você precisar enviar para vários endereços, sugiro ter uma tabela de pesquisa que contenha todos os formulários e o email para enviá-los. Isso pode ser implementado em XML ou em código (eu já vi os dois, embora não tenha certeza se é melhor). Isso ajudará a evitar que os remetentes de spam obtenham seus endereços de email na página do formulário.