«

»

Mar 30

Print this Post

Implementando Uma Arquitetura Em Camadas

Há alguns artigos atrás, eu falei sobre arquitetura de software e como a minha intenção naquele artigo era fazer um texto conceitual e não um tutorial. Não apresentei nenhum exemplo da maneira a qual eu vejo uma arquitetura.
Então resolvi escrever uma série de artigos com uma implementação da arquitetura que costumo adotar em meus projetos pessoais.
A ideia é seguir padrões de Orientação a Objetos e Segurança de Software e reaproveitar ao máximo de código possível.
Porém, quero deixar claro, que vou somente postar códigos que se referem aos padrões adotados por mim, os demais códigos ficarão por sua conta.
Para implementar esse modelo de arquitetura, eu divido minha aplicação em camadas e as mesmas serão listadas e explicadas abaixo:

  • DAO
  • Model
  • Controller
  • DTO
  • ViewHelper

Além da camada VIEW que não será detalhada nesse momento.
Farei um artigo mais pra frente, focado na camada de visualização.

DAO
Para iniciar, temos a camada DAO(Data Access Object), defino a camada DAO como a minha interface com o Banco de Dados da aplicação.
Muita gente costuma enfatizar que o DAO tem que ser uma “camada burra”. Ou seja, não tem nenhuma inteligência, não enxerga quem está lá fora(Model, Controller, DTO, VIEWS e etc…). Bom eu penso diferente, eu vejo o DAO como um cara “quase burra”. Ele é até burrinho, mas como falei para um amigo um dia desses. “O DAO é burro, mas sabe SQL”.
Vou explicar: Digamos que você precisa verificar, se um status na tabela do banco que o DAO representa é true, para definir a operação que você vai executar.
Eu gosto de fazer essa verificação através de um método dentro do DAO, que faz a consulta e retorna Boolean para que a decisão seja tomada, outra opção é o método do DAO retornar Number contendo a quantidade de registro encontrada, nesse tipo de exemplo é claro.
Algumas pessoas vão discordar, mas, para mim, é uma regra de negócios do banco de dados e deve ser tratada pelo seu responsável. Ou seja, o DAO.
E para detalhar esse exemplo, essa verificação será feita na hora da tomada de decisão, ou seja, na camada de modelo (Model), é que esse tipo de decisão deverá ser verificada. Mas como a camada de modelo não pode acessar o banco, a tal verificação deverá ser por intermédio de um método do DAO que retorna Boolean. Bom, abaixo entenderemos por que a camada de modelo não pode acessar o banco.

Model
Camada de modelo, costumo dizer que é só até aonde o dado “irregular” deve chegar, ou como brincamos onde trabalho. “Se um cara passar da camada de modelo sem seguir as regras da implementação, este deverá ter acesso liberado no DAO, porque ele é bom!”. Brincamos com isso, para simbolizar a responsabilidade do Model. É esta camada a responsável por intermediar as negociações dos clientes com o banco de dados, penso que toda regra de negócio que não deve ser aplicada ao Banco de Dados, ou seja, que não seja uma consulta SQL. Mas que tenha a ver com o que será feito no DAO, deverá ficar na camada de modelo, um exemplo é o mesmo exemplo que demos no DAO. A verificação para a tomada de decisão.
Se analisarmos agora o exemplo, entenderemos melhor e veremos que trata-se de uma validação através de uma consulta ao banco de dados, mas que não está sendo feita de um método do DAO para outro e sim da camada de modelo para o DAO e após isso a decisão é tomada corretamente.
Vamos a um exemplo visual.

Class model {
   public function Void realizarOperacao( dto ) {
      if( verificarStatatus( dto.getId() ) == true ) {
         this.dao.update( dto );
      } else { this.dao.save( dto ); }
   }
   private function Boolean verificarStatatus( id ) {
      return this.dao.verificarStatatus( id );
   }
}
Class dao {
   public function Void save( dto ) { // implementação para salvar dto no banco }
   public function Void update( dto ) { // implementação para editar um registro no banco }
   public function Boolean verificarStatatus( id ) {
      // select status;
      return ( rs.len == 1 ) ? true : false;
   }
}

No exemplo acima, vimos que a decisão de qual método chamar, foi tomada pela camada de modelo e não pelo DAO. Mas a verificação foi feita no DAO, ou seja o DAO não é totalmente burro, mas não é responsável por tomar decisões.
Devemos lembrar, que antes de executar a operação, os dados devem ser validados e testados para serem passados para o DAO somente em caso de serem confiáveis.
Ps. Os códigos acima, são algorítimos básicos e não tem base em linguagem nenhuma.

Controller
O Controller tem uma tarefa parecida com a do Model, porém ele é chamado pela camada de visualização, mas, ele não recebe dados como HTML e nem retorna dados deste tipo.
Se permitirmos que qualquer tipo de informação chegue ao controller, teremos uma balburdia de códigos dentro da camada de controle, tendo métodos grandes e difíceis de ler.
Para resolver esse problema eu utilizo o ViewHelper, este sim, faz interface direta com o HTML, recebe dados desordenados, organiza tudo e passa para o controller somente o necessário.
A camada de controle, vai pegar os dados, executará toda a regra de negócio da aplicação, “que não pertença ao banco de dados é claro” e interage com a camada de modelo.
No retorno dos dados, o controller mandará os dados brutos para o ViewHelper apresentá-los da melhor forma na tela do usuário.

DTO
A algum tempo, eu criava classes DAO com todos os campos da entidade, representados através de atributos e seus respectivos getters e setters. Dessa forma facilitava um salvamento, já que o DAO servia como um Objeto da aplicação. Por exemplo um DAO para representar a entidade Usuarios.
Para inserir um usuário no banco, implementava-se da seguinte forma:

Usuarios usuario = new Usuarios();
usuario.nome = “Paulo”;
usuario.save();

Mas dessa forma, ficava muito direto e a camada do banco ficava exposta no resto da aplicação. Para evitar esse tipo de problema, eu comecei a usar o DTO (Data Transfer Object) e como o nome já diz, é um objeto para transferência de dados. E com o DTO, fica mais eficaz validar, popular os dados no objeto e pode ir como parâmetro nas camadas envolvidas.
DTO é um objeto simples, contém os atributos da entidade, os getters e setters, um método que popula todos os atributos através de uma coleção de dados, um validador e alguns métodos que servem como facilitadores para debugger.
Veremos esses métodos e atributos mais a frente.

ViewHelper
O ViewHelper, é um ajudador já citado acima, esse ajudador é somente responsável por receber os dados do HTML e passar para o Controller de uma forma que o mesmo consiga realizar suas implementações de negócio e popular o DTO corretamente para dar andamento ao processo de solicitação.
Em caso de uma logica, que não necessitaria acessar o banco de dados, como uma manipulação de datas, moedas ou coisas do tipo, cabe ao ViewHelper fazer, sem precisar chamar o Controller, isolando o Controller para tarefas que envolvam as demais camadas da aplicação.
Nos próximos artigos, faremos a implementação de cada camada.

Até a próxima.
Paulo Teixeira.
Fonte: http://www.pauloteixeira.blog.br/site/index.php/content/2012/implementando-uma-arquitetura-em-camadas/

Permanent link to this article: https://ensina.me/coldfusion/implementando-uma-arquitetura-em-camadas/

Leave a Reply