Antigamente não existia grande necessidade de utilização de design patterns no desenvolvimento de software. Isso porque as aplicações eram extremamente simples e a manutenção, geralmente, era feita pelas mesmas pessoas que as construíam. Logo, não era necessário estabelecer padrões de desenvolvimento, uma vez que na maioria dos casos não haveria a necessidade de compartilhar o código com outros desenvolvedores para a realização de manutenções e melhorias.
Nos dias de hoje, entretanto, os padrões de projeto são uma necessidade, especialmente com o tamanho e a complexidade dos softwares desenvolvidos. Como as aplicações são desenvolvidas por equipes cada vez maiores, é obrigatório que todas essas pessoas sigam uma linha de raciocínio, um padrão de desenvolvimento. Isso faz com que o código seja melhor compartilhado e entendido pelas diferentes entidades que estão envolvidas no desenvolvimento. Sem contar o fato de que a qualidade do software tende a aumentar muito.
Outro ponto importante a favor dos design patterns é a facilidade de manutenção e documentação de código. Quando estamos seguindo um padrão, é natural que outros desenvolvedores o conheçam, e isso faz com que o código seja mais facilmente entendido. Não há nada mais complexo, no desenvolvimento de software, do que entender código mal feito e documentado. Assim, a alteração desse tipo de código é uma tarefa hercúlea. Com a utilização de um padrão, isso é muito simplificado.
Ao longo desse artigo veremos uma introdução básica ao desenvolvimento de software em camadas. Esse tipo de desenvolvimento permite uma fácil divisão entre diferentes equipes de programadores, sem que haja prejuízo no tempo de projeto. Então, poderemos focar no ponto principal de nosso artigo: design patterns da camada de acesso a dados, ou a DAL – do inglês Data Access Layer –, em especial os padrões Repository e Unit of Work. Veremos o porquê dessa utilização e como eles se comportam dentro de uma aplicação .NET.
Desenvolvimento de software em camadas
A separação lógica de conceitos em uma aplicação qualquer é parte essencial do conhecimento de qualquer programador/desenvolvedor. É extremamente importante que conheçamos os principais métodos para essa separação e como a aplicação irá se comportar nesses casos. Essa separação se faz essencial em aplicações conhecidas como “enterprise-level”, ou seja, aplicações de “nível-empresa”, em uma tradução literal. Trata-se de software mais complexo e, consequentemente, mais difícil de ser compreendido, mantido e desenvolvido. Por isso a importância de separarmos o projeto em vários pequenos pedaços. Em outras palavras, a arquitetura da aplicação é tão importante quanto qualquer código: você não consegue construir uma aplicação escalável e de fácil manutenção utilizando conceitos ruins em sua fundação.
Uma das formas de criar uma aplicação seguindo esses conceitos é a separação em camadas. Isso pode ser atingido de diversas maneiras, seja utilizando namespaces, diretórios ou mesmo projetos separados dentro de uma solução. A forma pela qual fazemos a separação é indiferente, desde que a separação seja bem-feita. E isso não diz respeito simplesmente ao código: é preciso que haja um entendimento do que deve ser feito em cada camada para que o software funcione.
A Figura 1 representa de forma simples o conceito de camadas em uma aplicação qualquer. Note que são várias camadas demonstradas, e nem todas as aplicações terão todas elas. A ideia é que o desenvolvedor, analista ou projetista do software seja capaz de entender quais são as camadas que não são necessárias em determinado projeto e retirá-las, sem prejudicar o funcionamento geral do projeto.
Figura 1. Arquitetura típica de aplicação em camadas
As camadas típicas são explicadas a seguir:
· Modelo de domínio: nessa camada, é comum a utilização de um padrão de projeto chamado Domain Model. Esse padrão foi criado para organizar a lógica de negócios da aplicação, incluindo relacionamentos entre entidades;
· Serviços de domínio: também se trata de uma camada referente à lógica de negócios da aplicação, contendo os serviços necessários ao modelo de domínio;
· Serviços: corresponde aos serviços da aplicação como um todo, fazendo a ligação entre a lógica de negócios e a apresentação da aplicação;
· Apresentação: a camada de apresentação da aplicação corresponde ao que o usuário irá enxergar da aplicação;
· Experiência do usuário: essa camada corresponde a alguns detalhes específicos do que os usuários devem experimentar utilizando a aplicação;
· Infraestrutura e repositórios: essas camadas podem ser vistas de forma conjunta, referentes à camada conhecida como DAL – Data Access Layer – ou Camada de Acesso a Dados. A infraestrutura diz respeito a detalhes da aplicação, como logs, enquanto a camada Repository faz parte do escopo de nosso artigo. Essa camada é a que contém os repositórios de dados, abstraindo a infraestrutura da base de dados.
Com isso, podemos notar a importância que possui a separação da aplicação em camadas. A capacidade de dividir o desenvolvimento é grande aliada no caso de aplicações enterprise-level, com as quais devemos lidar em grande parte do tempo. Isso porque diferentes equipes devem atacar diferentes camadas, podendo realizar o desenvolvimento paralelamente sem prejuízos ao produto final.
A Camada de Acesso a Dados - DAL
A Camada de Acesso a Dados – DAL ...
