Projetando a interface do usuário (e mais camadas) em ASP.NET

Grande parte do sucesso de qualquer aplicação Web depende da qualidade de sua interface de usuário. Tanto quanto os usuários finais estão em causa, a interface do usuário é

a aplicação: Os usuários não estão interessados ​​nos detalhes do modelo de dados ou o design das classes de acesso a dados.

Em um aplicativo Web ASP.NET, a interface do usuário consiste em uma série de páginas .aspx que são processados ​​para o navegador usando HTML padrão. Projetando a interface do usuário é simplesmente uma questão de decidir quais as páginas que são necessários (e em que seqüência) - e preencher as páginas com os controles apropriados.

HTML padrão tem um conjunto surpreendentemente limitado de controles de entrada do usuário:

• botões
• As caixas de texto
• Listas drop-down
• As caixas de seleção
• Botões do rádio

No entanto, ASP.NET oferece muitos controles que construir sobre esses controles básicos. Por exemplo, você pode usar um controle GridView para apresentar dados de um banco de dados em um formato tabular.

Todos os controles ASP.NET são eventualmente processada para o navegador, usando HTML padrão. Como resultado, mesmo os controles ASP.NET mais complicados são simplesmente compostos feitos de controles HTML padrão e elementos de formatação HTML (como tabelas).

Projetando a interface do usuário pode rapidamente tornar-se o aspecto mais complicado de uma aplicação Web. Embora o design da interface do usuário não tem regras rígidas e rápidas, aqui estão algumas orientações que você deve ter em mente:

• Considere a frequência com que o usuário utilizará cada página e quão familiar ele ou ela vai estar com o aplicativo. Se o usuário trabalha com a mesma página repetidamente durante todo o dia, tentar fazer a entrada de dados o mais eficiente possível. No entanto, se o usuário utilizar a página de uma única vez em quando, errar no lado de fazer a página auto-explicativa para que o usuário não tem que se esforçar para descobrir como usar a página.
• Lembre-se que o usuário está no controle da aplicação e os usuários são bastante imprevisíveis. Os usuários podem dar-se no meio de uma sequência de entrada de dados, ou inesperadamente bateu o botão Voltar do navegador.
• Alguns usuários, como o mouse, outros, como o teclado. Não force a sua preferência no usuário: certifique-se de sua interface funciona bem para rato, bem como usuários de teclado.
• protótipos revisão do projeto de interface do usuário com usuários reais. Ouvir suas sugestões a sério. Eles provavelmente têm uma idéia melhor do que você faz do que a interface do usuário deve ser semelhante e como ele deve se comportar.
• Web sites de estudo que você considera ter boas interfaces.

Projetando a Camada de Regras de Negócios

Regras do negócio são a parte de um programa que implementa as políticas de negócios ditadas pela aplicação. Aqui estão alguns exemplos de regras de negócios:

• Se um cliente ser concedido um pedido de crédito?
• Quanto de um desconto deve ser aplicado a uma determinada ordem?
• Quantas cópias do Formulário 10432 / J precisam ser impressos?
• Quanto transporte e manuseio deve ser pregado em uma factura?
• Quando deve um item de inventário que está com pouco estoque ser reordenadas?
• Quanto doente licença deve um empregado começar antes gestores perguntar se ele ou ela tenha sido esqui em vez de ficar em casa doente?
• Quando deve uma conta a pagar ser pago para tirar proveito de descontos enquanto maximiza a bóia?

A chave para projetar a parte de empresários regras de uma aplicação é simplesmente identificar as regras de negócios que devem ser implementadas e separá-los, tanto quanto possível, de outras partes do programa. Dessa forma, se as regras mudam, apenas o código que implementa as regras precisa ser mudado.

Por exemplo, você pode criar uma classe para lidar com políticas de descontos. Em seguida, você pode chamar métodos desta classe sempre que você precisa para calcular desconto de um cliente. Se as mudanças de política de desconto, a classe de desconto pode ser atualizado para refletir a nova política.

Idealmente, cada regra de negócio deve ser implementada apenas uma vez, em uma única classe que é usada por cada programa que precisa dele. Com demasiada frequência, as políticas de negócios são implementadas uma e outra vez em vários programas - e se as mudanças políticas, dezenas de programas precisam ser atualizados. (Isso ainda dói para pensar, não é?)

Projetando o Data Access Layer

Grande parte do trabalho de projetar a Camada de Acesso a Dados envolve a concepção do próprio banco de dados. Aqui estão algumas dicas sobre projetar a camada de acesso a dados:

• Para começar, você deve decidir o servidor de banco de dados para usar (por exemplo, SQL Server ou Oracle).
• Você vai precisar para projetar as tabelas que compõem o banco de dados e determinar quais colunas cada mesa vai exigir.
• Você também deve decidir quais as técnicas básicas que você usará para acessar os dados. Por exemplo, você vai escrever personalizados classes de acesso a dados que acessam o banco de dados diretamente, ou você vai usar o controle SqlDataSource do ASP.NET para acessar o banco de dados? E você vai usar procedimentos armazenados ou código as instruções SQL usadas para acessar os dados diretamente no código do aplicativo?