Fernando Mantoan Desenvolvimento e tecnologia da informação no geral

Neste segundo artigo sobre uma proposta de arquitetura utilizando o framework CodeIgniter, falarei sobre os design patterns escolhidos para compor a arquitetura, mais especificamente os patterns que os programadores necessitarão implementar e não os patterns do CodeIgniter em si. Caso vocês tenham curiosidade em ver os Design Patterns que o CodeIgniter implementa, vejam este post, onde o autor fala especificamente sobre isso.

Design Patterns (Padrões de Projetos)

Baseando-se no livro PHP Profissional, escrito por Alexandre Altair de Melo e Mauricio G. F., página 189, os Design Patterns podem ser definidos como sendo soluções para problemas comuns em diversos cenários no desenvolvimento de software onde cada padrão terá:

• um nome, para que se possa descrever um problema de projeto, suas soluções e consequências em uma ou duas palavras;
• uma descrição do problema, para se saber quando aplicar o padrão;
• uma solução, onde serão descritos os elementos que compõem o projeto, seus relacionamentos, suas responsabilidades e colaborações;
• as consequências como sendo os resultados, vantagens e desvantagens da aplicação do padrão.

Design Patterns escolhidos para a arquitetura

Para a arquitetura proposta, será necessária a aplicação de alguns padrões para se obter uma maior organização de código, separando-se cada coisa em sua devida camada lógica, ganhando maior abstração em cada parte da aplicação. Existem alguns patterns que são fornecidos pelos frameworks escolhidos e outros que deverão ser implementados no CodeIgniter, para que ele ofereça um suporte “nativo” a eles. Os padrões que a arquitetura terá são:

• Model-View-Controller
  • Não especificamente um padrão de projeto e mais um padrão arquitetural, é o padrão que prega a separação entre a regra de negócio (model) e a apresentação dos dados (view) da aplicação. Para que ambas as partes consigam se interligar, existe um controlador de fluxo da aplicação (controller) que será responsável por pegar dados do model e passar para a view, ou passar requisições da view para o model. Na arquitetura, o MVC já é fornecido pelo CodeIgniter e ganhou ainda mais abstração com o Smarty, que fornece uma View completamente sem código PHP. O model pode ser abstraído em 2 partes, uma para DAO e outra para o Model em si (representação dos dados do banco de dados), e as regras de negócio ficarão na camada Facade.
• Facade Pattern
  • Um padrão de projeto bastante comum em aplicações Java e que se tornou bastante útil nessa arquitetura. Um Facade pattern tem como principal objetivo melhorar a legibilidade do código entre camadas, no caso da arquitetura, seria a legibilidade do Controller e do Model, agregando em seus métodos códigos com várias linhas e fornecendo métodos que serão comuns a várias outras partes da aplicação. No caso dessa arquitetura cada controller terá sua própria Facade, essa extendendo de uma Facade abstrata, devendo implementar alguns métodos que serão definidos nela. Essas Facades conterão regras de negócio, deixando o Model e o Controller um pouco mais “limpos” de código.
• Data Access Object
  • O DAO não está entre um dos 23 Design Patterns definidos pela Gang of Four, porém está entre os patterns corporativos mais utilizados em aplicações no geral. O conceito dele é simples, fornecer um objeto onde se tenha apenas métodos de persistência. Na arquitetura o DAO irá trabalhar com o Model gerado pelo Doctrine, contendo métodos de acesso ao banco de dados.

Com os padrões de projetos definidos, no próximo artigo apresentarei as implementações necessárias para tornar cada padrão de projeto o mais integrado possível com o framework CodeIgniter e posteriormente desenvolverei uma aplicação para gestão de tarefas utilizando a arquitetura definida. Até a próxima.