Dicas para evitar grande bola de lama com ASP.NET WebForms

Question

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.

Answer 1

• 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.

Answer 2

Eu geralmente tentar ficar clara dele ... mas quando eu uso WebForms, eu siga estes preceitos:

1. 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.
2. 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.
3. 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.
4. 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.
5. Evite VIEWSTATE :. Ver comentários # 4

Answer 3

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.

Answer 4

Comece com Master Pages no dia # 1 -. A sua dor voltando para retrofit

Answer 5

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

Answer 6

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