Usando Arquiteturas em camadas no ASP.NET

Uma abordagem para aplicações web design é se concentrar em camadas bem definidas de arquitetura do aplicativo. Esta aproximação é semelhante à maneira como um arquitecto projeta um edifício. Se você já viu os planos de construção detalhados para um arranha-céu, você sabe os planos de construção incluem modelos separados para a fundação, estrutura, telhado, canalização, electricidade e outros pisos do edifício.

Com uma arquitetura em camadas, os especialistas podem projetar e desenvolver os "andares" - chamada camadas - independentemente, desde que as ligações entre as camadas (a Interfaces) São cuidadosamente pensado.

As camadas devem ser independentes um do outro, tanto quanto possível. Entre outras coisas, isso significa que atendendo algumas deve-dos e te pobres:

• Cada camada deve ter um foco definido. Para projetar as camadas corretamente, é necessário definir claramente as funções e responsabilidades de cada camada.
• Camadas deve cuidar de seus próprios negócios. Se uma camada é responsável pela interacção com o utilizador, apenas aquela camada é permitido comunicar com o utilizador. Outras camadas que precisam obter informações do usuário deve fazê-lo através da camada de interface do usuário.
• Claramente protocolos definidos deve ser configurado para as camadas de interagir uma com a outra. A interacção entre as camadas ocorre apenas através destes protocolos.

Note-se que as camadas não estão vinculados diretamente a qualquer aplicação em particular. Por exemplo, uma arquitetura pode funcionar igualmente bem para um sistema de pedidos on-line e para um fórum on-line. Como resultado, a arquitetura em camadas não tem nada a ver com o ERDs que definir um banco de dados ou os diagramas de fluxo de dados que definem como os fluxos de dados dentro do aplicativo. É uma estrutura separada.

Quantas camadas?

Existem várias abordagens comuns para a arquitetura de aplicações que variam dependendo do número de camadas utilizadas. Um esquema comum é quebrar a aplicação em duas camadas:

• Camada de aplicação: O design da interface do usuário e da implementação de políticas de negócios são tratados nesta camada. Esta camada pode também lidar com lógica de transação - o código que atualizações de dados grupos em transações e garante que todas as atualizações em uma transação são feitas de forma consistente.
• Acesso a Dados Camada: O motor de banco de dados subjacente que suporta a aplicação. Esta camada é responsável por manter a integridade da base de dados. Alguns ou todos os lógica de transação pode ser implementado nesta camada.

No modelo de duas camadas, a camada de aplicação é as páginas da Web ASP.NET que definem as páginas apresentadas ao usuário, bem como os arquivos de código-behind que implementam a lógica do aplicativo. A camada de acesso a dados é o servidor de banco de dados que gerencia o banco de dados, como o Microsoft SQL Server ou Oracle.

Note-se que ASP.NET 2.0 não exige que você coloque código da lógica do aplicativo em um arquivo separado de código subjacente. Em vez disso, você pode intercalar o código da lógica com o código de apresentação no mesmo arquivo. No entanto, é quase sempre uma boa idéia usar arquivos de código-behind separados para separar a lógica do aplicativo a partir do seu código de apresentação. Todas as aplicações apresentadas neste livro usar arquivos de código-behind separados.

A divisão entre o aplicativo e camadas de acesso a dados nem sempre é tão claro quanto poderia ser. Por motivos de desempenho, a lógica transacção é muitas vezes deslocado para o servidor de banco de dados (na forma de procedimentos armazenados), e regras de negócios são muitas vezes implementado no servidor de banco de dados com restrições e gatilhos. Assim, o servidor de banco de dados, muitas vezes lida com alguns dos lógica do aplicativo.

Se esta desordem o incomoda, você pode usar um arquitetura de três camadas, o que acrescenta uma camada adicional de lidar com regras e políticas de negócios:

• Camada de Apresentação: Esta camada lida com a interface do usuário.
• Regras de Negócio da camada: Esta camada lida com as regras de negócios do aplicativo e políticas. Por exemplo, se um aplicativo de vendas concede descontos para certos usuários, a política de descontos é implementado nesta camada.
• Acesso a Dados Camada: O modelo de banco de dados subjacente que suporta a aplicação.

Criando uma camada separada para regras de negócios permite que você separe as regras do projeto de banco de dados ea lógica de apresentação. As regras de negócios estão sujeitos a alterações. Colocando-os em uma camada separada, você tem uma tarefa mais fácil de mudar-los mais tarde do que se eles estão incorporados na interface do usuário ou de design de banco de dados.

MVC

Outro modelo comum para a criação de aplicativos da Web é chamado MVC (MVC). Nesta arquitetura, o aplicativo é dividido em três partes:

• Modelo: O modelo é, com efeito, camada de negócios do aplicativo. Ele geralmente consiste de objetos que representam as entidades empresariais que compõem o aplicativo, como clientes e produtos.
• Visão: o Visão é a interface de usuário do aplicativo. Em um aplicativo Web, este consiste em uma ou mais páginas HTML que definem a aparência do aplicativo.
• Controlador: o controlador gere os eventos processados ​​pela aplicação. Os eventos são normalmente gerados por acções de interface do usuário, tais como o usuário clicar em um botão ou selecionando um item de uma lista drop-down.

Em um aplicativo ASP.NET típico, o arquivo.aspx implementa o Ver- as funções do modelo e do controlador são combinados e manipulados pelo código-behind arquivo. Assim, o ficheiro de código subjacente pode ser pensado como o modelo de controlador.

Você pode, é claro, separar as funções do modelo e do controlador através da criação de classes separadas para as entidades de negócios. Para simplificar, as aplicações neste livro manter o modelo e controlador de funções combinadas no arquivo code-behind.