No mundo dos grandes negócios e das aplicações corporativas é muito como comum se ouvir falar em arquitetura de software, camada de negócios, camada de dados, e assim por diante. Para o desenvolvedor que atua sozinho ou para pequenas equipes a ênfase esta em se terminar o serviço o mais rápido possível e decisões quanto a arquitetura da aplicação são freqüentemente deixadas de lado.
No entanto a utilização de camadas em uma arquitetura de software é muito simples de implementar e fornece grandes benefícios. Sua utilização permite abstrair toda a lógica de acesso dados em um conjunto de classes e fornece uma interface consistente, além de facilitar a manutenção, a portabilidade e a escalabilidade da aplicação.
Mas parece que quando se fala em camadas há uma certa hesitação ou confusão quanto a quantidade de camadas usar e como distribuí-las em uma aplicação pois não existe uma receita pronta que sirva como um modelo para todas as aplicações, pois cada projeto tem suas particularidades que devem ser analisadas em detalhes antes de tomar uma decisão.
Dessa forma se sua aplicação possui uma lógica de negócio complexa talvez houvesse a necessidade de criar uma arquitetura em 3 camadas com uma camada de negócios (Business Logic Layer, em inglês), uma camada de acesso a dados(Data Access Layer) e a camada de apresentação (UI). No entanto se sua aplicação é uma aplicação simples uma arquitetura com 2 camadas com uma camada de acesso a dados e a camada de apresentação seja o bastante.
Camadas: Separação Entre Componentes
Para melhor organizar a manter componentes, é crucial que sejam separados por algum critério. Isolando-os em grupos é possível diminuir o acoplamento entre os componentes, fazendo com que as mudanças em um grupo não impactem muito em outro grupo.
Entre as diversas formas possíveis de separar os componentes, está a técnica de Camadas. Ao separar componentes em grupos chamados Camadas (Layers), o projetista agrupa componentes por responsabilidade em comum que possuam.
Uma aplicação Java EE tradicional, por exemplo, usa o modelo de 3 Camadas: Apresentação, Negócios e Persistência. Na Camada de Apresentação estão todas as classes e demais artefatos (como páginas JSP) relacionados com a interação entre o usuário e a aplicação. A Camada de Negócios contêm a modelagem do domínio do problema em classes de negócio e a Camada de Persistência contém as classes com conhecimento sobre como persistir objetos no banco de dados (por exemplo, as DAOs).
Utilizando Camadas o projetista tem um critério a utilizar quando decide agrupar duas ou mais classes, mas o uso de Camadas não diz nada sobre como estes grupos se comunicam. O máximo que o uso de Camadas diz é sobre se estas são transparentes (ou abertas) ou opacas (fechadas). Camadas transparentes não evitam que uma superior enxergue a inferior, as opacas sim.
As Camadas promovem o encapsulamento (uma Camada não vai saber o que tem dentro da outra) e a coesão (componentes parecidos ficam no mesmo grupo).
Na arquitetura com 2 camadas a camada de apresentação chama diretamente a camada de acesso a dados.
Na arquitetura com 3 camadas a camada de apresentação chama a camada de negócios que chama a camada acesso a dados.
Observe que em nenhum dos casos estamos fazendo o acesso direto ao banco de dados pois sempre estamos trabalhando com uma camada de acesso a dados.
Usando uma camada de acesso a dados(DAL) podemos retornar um DataSet ou DataTable e tratar o retorno na camada de apresentação.
Com uma camada de negócios (BLL) podemos efetuar efetuar uma validação de regra de negócio e em seguida passar os objetos para a camada de apresentação.
Estes cenários são perfeitamente realistas e aplicáveis e ambos reduzem a quantidade de código e apresentam um melhor desempenho do que a arquitetura one-button-click, aquela velha técnica de colocar um botão de comando e no seu evento Click incluir todo o código necessário para validação , acesso a dados, etc.