Dicas para evitar grande bola de lama com ASP.NET WebForms
Pergunta
Embora ASP.NET MVC parece ter todo o hype estes dias, WebForms ainda são comuns. Como você mantém a sua sã projeto? Vamos recolher algumas dicas aqui.
Solução
- Criar controles de usuário da web para qualquer coisa que será mostrado em mais de uma página que não é uma parte do conteúdo do tipo masterpage. Exemplo:. Se o seu aplicativo exibe informações sobre o produto 10 páginas, é melhor ter um controle de usuário que é usado em 10 páginas ao invés de cut'n'pasting o código de exibição 10 vezes
- Coloque o mínimo de lógica de negócios no código por trás possível. O atrás de código deve adiar para a sua camada de negócios para realizar o trabalho que não está diretamente relacionada ao colocar as coisas na página e enviar dados e para trás a partir da camada de negócios.
- Não reinventar a roda. Um monte de codebehinds desleixado que eu vi são feitos de código que está fazendo as coisas que o quadro já fornece.
- No, blocos gerais de script evitar no html.
- não tem uma página fazer muitas coisas. Algo que eu vi uma e outra vez é uma página que digamos tem modos add e edit. Isso é bom. No entanto, se você tem muitos sub-modos para adicionar e editar, você é melhor ter várias páginas para cada modo de sub com reutilização através de controles de usuário. Você realmente precisa para evitar ir um monte de IFs aninhados para determinar o que o usuário está tentando fazer e, em seguida, mostrando as coisas corretas, dependendo isso. As coisas ficam fora de controle rapidamente se sua página tem muitos estados possíveis.
- Saiba / Grok o ciclo de vida da página e usá-lo para sua vantagem. Muitas páginas feio codebehind que eu vi poderia ser mais limpas, se o codificador compreendeu o ciclo de vida de página melhor.
Outras dicas
Eu geralmente tentar ficar clara dele ... mas quando eu uso WebForms, eu siga estes preceitos:
- Mantenha o HTML resultante limpa : Só porque você não é mão-de codificação cada
<div>
não significa que o código gerado tem de se tornar um pesadelo ilegível. Evitar controles que produzem código feio pode render em tempo de depuração reduzida mais tarde, fazendo problemas mais fáceis de ver. - Minimizar dependências externas : Você não está sendo pago para depurar código de outras pessoas. Se você do optar por confiar em componentes 3-parte, em seguida, obter o código fonte para que você não precisa perder invulgarmente grandes quantidades de tempo corrigindo seus erros.
- Evite fazer muito em uma página : Se você está implementando "modos" complexos para uma determinada página, considere dividi-lo em vários, páginas de modo único, talvez usando páginas mestras para fatorar aspectos comuns.
- Evite postback : Esta sempre foi uma idéia terrível, e não ficou nem um pouco menos terrível. As dores de cabeça que você vai economizar por não usar controles que dependem de postagem são um bônus agradável.
- Evite VIEWSTATE :. Ver comentários # 4
Com grandes projetos a melhor sugestão que posso dar é para seguir um padrão de design comum que todos os seus colaboradores estão bem treinados e bem conscientes. Se você está lidando com ASP.NET, em seguida, as duas melhores opções para mim são:
o Model View Presenter ( embora este é agora Supervisor Controller e passiva Ver ). Este é um modelo sólido empurrando separação entre a sua interface de usuário e modelo de negócio que todos os seus desenvolvedores pode seguir sem muita dificuldade. O código resultante é muito mais testável e sustentável. O problema é que ela não é aplicada e que são obrigados a lotes de escrita de código de suporte para implementar o modelo.
o ASP.NET MVC O problema com este é que é na visualização. Falei com Tatham Oddie e ser mencionado que é muito estável e utilizável. Eu gosto dele, ele impõe a separação de conceitos e faz isso com código extra mínima para o desenvolvedor.
Eu acho que qualquer modelo que você escolher, a coisa mais importante é ter um modelo e para garantir que todos os seus desenvolvedores são capazes de furar a esse modelo.
Comece com Master Pages no dia # 1 -. A sua dor voltando para retrofit
Seguindo o que Odd disse, estou tentando uma versão do MVP chamado modelo de apresentação que está funcionando bem para mim até agora. Eu ainda estou recebendo um entendimento dela e adaptá-lo para o meu próprio uso, mas é refrescante a partir do código que usei para escrever.
Confira aqui: Apresentação Modelo
Use o controle de versão e uma estrutura de pastas para evitar que muitos arquivos de todo o ser na mesma pasta. Não há nada mais doloroso do que espera para o Windows Explorer para carga alguma coisa, porque há mais de 1.000 arquivos em uma pasta e tem que carregar todos eles quando a pasta é aberta. A convenção sobre variáveis ??e métodos de nomeação também é bom ter adiantado se possível, de modo que não há essa miscelânea de código onde diferentes desenvolvedores colocar todos os seus toques exclusivos e dolorosamente shows.
Usando padrões de projeto pode ser útil na organização de código e tê-lo escala muito bem, por exemplo, um padrão de estratégia pode levar a um tempo mais fácil quando se tem de adicionar um novo tipo de produto ou dispositivo que tem de ser suportado. Semelhante para o uso de alguns Adapter ou fachada.
Por fim, conhecer as normas que seus formulários vão defender:? É apenas para usuários do IE ou se qualquer de IE, Firefox ou Safari facilmente carregar o formulário e de boa aparência