.NET - Definindo um infra-estrutura baseada em camadas

Nunca se discutiu tanto sobre qual a melhor arquitetura para desenvolvimento de software como hoje. Basta você procurar no Google sobre o assunto e vai encontrar toneladas de referências e links que remetem ao tema. Isso é muito bom pois quanto maior a troca de informações mais subsídios temos para tomar uma decisão neste sentido.

Neste artigo eu procuro abordar o tema da criação de uma infra-estrutura baseada em camadas para desenvolvimento de aplicações na plataforma .NET com base em minha experiência e nas inúmeras referências encontradas na web com o objetivo de contribuir de alguma forma para que você possa compreender os conceitos envolvidos nesta questão.

Como o assunto é extenso pretendo tratar dos seus fundamentos de uma forma clara e objetiva para depois , em futuros artigos, avançar para tópicos mais avançados; como eu sempre digo: "primeiro o arroz com feijão, depois o camarão..."

Mas quais os problemas que envolvem esta celeuma ?

De forma resumida podemos enumerá-los da seguinte forma:

  1. Separação do código de acesso aos dados do código da lógica de negócios e do código da camada de apresentação de forma a tornar a aplicação mais fácil de manter e mais fácil de portar;
  2. Isolar a arquitetura de acesso a dados de forma a suporta diferentes banco de dados de forma que a camada com código das regras de negócio e a camada de apresentação dos dados não seja afetada quando houver necessidade de trocar o banco de dados;
  3. Definir uma camada de regras de negócio que exponha as informações retornadas pela camada de acesso aos dados usando o formato da orientação a objetos através do processo do mapeamento objeto relacional (OR);

Nos anos mais recentes o termo desenvolver em camadas tornou-se muito familiar para quem trabalha com desenvolvimento de software; fala-se geralmente em desenvolvimento em n-camadas, em 3-camadas, camada de acesso a dados, camada de negócios, camada de apresentação, etc.

Mas afinal o que vem a ser isso ?

De forma bem simples o desenvolvimento em camadas procurar dividir a funcionalidade , componentes e o código para uma aplicação, seja para web ou para desktop, em camadas distintas que podem ser delineadas da seguinte forma:

Nota: Na literatura encontram-se com frequência os termos tiers e layers, em inglês, que geralmente são traduzidos como camadas. Olhando com atenção, embora a diferença seja bem sutil, compreende-se que tiers refere-se a uma separação física dos componentes (diferentes Assemblies, DLLs, arquivos),  enquanto layers aponta para uma separação lógica dos componentes com classes distintas e diferentes espaços de nomes.

No Visual Studio, podemos ter os dois tipos de separação em aplicações Web ou Windows Forms:

1- Criação de projetos distintos em uma solução - Separação física de componentes em assemblies distintos com deploy em locais distintos:

Vemos aqui uma solução e 3 projetos distintos:

1- Projeto Web
2- Projeto Windows Forms
3- Projeto Smart Device

Obs: Para criar projetos distintos crie uma solução usando o template Blank Solution (Other Project Types -> Visual Studio Solutions) e no menu File selecione Add -> New Project para incluir novos projetos.

 

2- Criação de um projeto em uma solução - Separação lógica de componentes em pastas e sub-pastas distintas com utilização de namespaces para organizar as classes:

Vemos aqui uma solução com um projeto web e diversas pastas contendo código e recursos usados no projeto.

As pastas App_Code , App_Data, App_Themes e App_LocalResources são pastas especiais do sistema.

A utilização de projetos distintos em uma solução com a separação dos componentes em assemblies distintos parece ser mais indicada para grandes projetos pois se torna mais difícil e trabalhoso tratar com diversos projetos distintos e gerenciar as suas dependências e relacionamentos.

Para projetos de pequeno e médio porte a separação lógica dos componentes parece ser a forma mais produtiva e adequada de infra-estrutura a ser adotada, ainda mais com ao advento da versão 2.0 da plataforma .NET que trouxe diversas melhorias que incentivam este tipo de infra-estrutura e modelo de distribuição.

Nota: Você pode usar a separação física dos componentes criando projetos distintos em projetos de pequeno porte mas isso não traria nenhuma vantagem extra.

Para aplicações web a pasta especial chamada App_Code faz com que qualquer código que seja nela colocada (e também em suas sub-pastas) seja compilado automaticamente em tempo de execução e referenciado pelo resto da aplicação. Esta compilação automática e sob demanda torna mais fácil e rápido testar a sua aplicação pois você pode realizar qualquer alteração no código da aplicação enquanto ela esta rodando que as alterações serão compiladas na próxima requisição.

Ainda para aplicações web, a pasta App_Data pode ser usada como repositório para o banco de dados, e, no caso do SQL Server, mesmo a versão Express, basta você copiar o seu arquivo .mdf para esta pasta e anexá-lo de forma dinâmica pela definição do caminho na string de conexão usando o novo atributo AttachDBFnomedoarquivo que estará apto a realizar o deploy do seu projeto apenas copiando a estrutura do seu projeto para o servidor remoto sem ter que realizar nenhuma configuração adicional. (XCOPY deploy).

Na continuação deste artigo irei abordar a definição da camada de acesso a dados ou Data Access Layer (DAL); conceitos, definições e formas de implementação.

Eu sei é apenas .NET , mas eu gosto...

referências:

José Carlos Macoratti