DAO e Table Gateway

Oi Marcelo, tudo bom?

Tanto DAO, quanto Table Gateway, quanto Repository, entre outros padrões de projeto que focam nessa parte de contato com o banco são bastante semelhantes.

O que muda de um pro outro na maioria das vezes é a motivação.

Todo padrão de projeto tem um contexto no qual se aplica.

Uma boa fonte de consulta para design patterns universal é o Design pattern do Erich Gamma =)

Oi André!

Entendo que há motivações e contextos senão não existiriam =]

Porém, o que eu gostaria mesmo é da diferença na prática. Ou um exemplo, se possível, por favor.

Obrigado desde já !

Perdão, acredito que eu não tenha me expressado bem.

A diferença é o motivo pelo qual você escolheu o pattern. O resultado de ambos é praticamente o mesmo. Isolar o código do banco de dados da aplicação back-end. Facilitar a manutenção caso haja alguma mudança nesse contato com o banco.

Cada um faz isso de uma forma.

O Table Gateway segue a abordagem de representar a tabela em sí, realizar a ponte entre os dados da tabela e a apliacação.

O Data Access Object já segue a abordagem de desacoplamento do código de back-end do código de acesso ao banco. Com o DAO normalmente seguimos para criação de interfaces justamente para garantir esse desacoplamento.

Em ambos você precisará criar classes que isolam o seu código back-end de códigos SQL, ou que isolem a ferramenta que você utiliza para realizar o contato com o banco. O que vai mudar de um pro outro, drasticamente, é a motivação. Qual problema você está enfrentando.

Se seu problema é representar uma tabela no back-end, talvez a melhor abordagem seja o TableGateway. Se seu problema é o código SQL misturado com seu código back-end, talvez o DAO seja sua escolha.

Todo pattern tem um problema que ele soluciona. Comparar dois patterns é comparar dois problemas e duas soluções.

No nosso caso, os dois patterns atacam uma mesma area, em em soluções que resolvem problemas bem semelhantes. Por isso, talvez fique um pouco abstrato mesmo a diferença na prática =)

Obrigado por essa luz inicial, André. No entanto, poderia clarificar com um exemplo de cada uma por favor no nosso querido PHP ? Obrigado desde já!

Exemplo de DAO em um modelo Produto:

public interface CrudDao {
    public function create(Produto $produto);
    public function read();
    public function update(Produto $produto);
    public function delete(int $id);
}
public interface ProdutoDao extends CrudDao{
    public function findAllByPrice(double $price);
    public function findOneByName(string $name);
}
public class ProdutoDAO implements ProdutoDao {
    public function create(Produto $produto) {
        // implementa a query, ou persiste o dado pelo ORM escolhido
    }
    public function read(){
        // seleciona todos os produtos no banco
    }
    public function update(Produto $produto){
        // realiza a lógica de atualização do produto
    }
    public function remove(int $id){
        // remove o registro do banco
    }
    public function findAllByPrice(double $price){
        // realiza a query para buscar todos com o preço informado
    }
    public function findOneByName(string $name){
        // encontra um produto com o nome passado
    }
}

A ideia aqui é que conseguimos extrair em interfaces toda a lógica envolvendo o contato de qualquer modelo do sistema com o banco em uma interface (CrudDao) e qualquer contato de um Produto (que faz parte do modelo) em ProdutoDao. Para finalizar implementamos toda a lógica concreta em ProdutoDAO, a classe que vamos instanciar futuramente para manipular o produto no banco =)

Table Gateway no mesmo modelo:

public class ProdutoGateway {
public function create(Produto $produto) {
        // implementa a query, ou persiste o dado pelo ORM escolhido
    }
    public function read(){
        // seleciona todos os produtos no banco
    }
    public function update(Produto $produto){
        // realiza a lógica de atualização do produto
    }
    public function remove(int $id){
        // remove o registro do banco
    }
    public function findAllByPrice(double $price){
        // realiza a query para buscar todos com o preço informado
    }
    public function findOneByName(string $name){
        // encontra um produto com o nome passado
    }
    // aqui também cabe funcionalidades em relação a tabela em sí.
    public function setOptions(array $options){
        // atualiza configuração da tabela
    }
}

As duas implementações são bem semelhantes, a diferença é o objetivo de se ter criado cada uma. Uma leve diferença é que, como o TableGateway representa a tabela em sí no back-end, a gente pode adicionar algumas funcionalidades que envolvem a tabela. Algo que não entraria no escopo do DAO.

Como eu disse antes, comparar os dois é comprar dois problemas diferentes. O resultado final é bem semelhante porque eles resolvem praticamente o mesmo problema.

Outro padrão que se encaixaria extremamente semelhante nessa discussão seria o Repository. Que realiza basicamente a mesma coisa, porém com uma motivação muito mais genérica. Diferenciar esses patterns praticamente falando é bem abstrato. Porque a diferença entre eles não está na prática, está na teoria.

De qualquer forma, espero ter ajudado.

Qualquer coisa é só falar =)

Abraço e bons estudos.

Certo, André,

"Uma leve diferença é que, como o TableGateway representa a tabela em sí no back-end, a gente pode adicionar algumas funcionalidades que envolvem a tabela"

quais funcionalidades ?

// aqui também cabe funcionalidades em relação a tabela em sí.
    public function setOptions(array $options){
        // atualiza configuração da tabela
    }

Dados relacionados à tabela em sí. Configurações da tabela, etc. Tendo em mente que o pattern reflete a tabela, não o modelo como o DAO, cabe nele qualquer informação relacionada à tabela como estrategia de geração da chave primaria, qual coluna é a chave primaria, quais relacionamentos há e assim por diante.