Repositório

O repositório administra o ciclo de vida de Entidades, Objetos de Valor e Agregados, fornece operações de criação, alteração e exclusão de objetos.

Repositório deve existir apenas para a raiz do agregado e apenas para os objetos que precisem de acesso direto. O repositório fornece ao cliente uma maneira simples de obter objetos persistentes, além de tornar o design do aplicativo e do domínio desacoplados da tecnologia de persistência.

Esse é uma padrão que causa muita dúvida, já que comumente utilizamos mais o padrão DAO para fazer acesso a dados. Alguns desenvolvedores acreditam que basta alterar o nome do DAO para repositório que esta fazendo uso deste padrão, ou que ele é apenas uma interface na qual o DAO implementa. Porém, esses pensamentos são errados.

O DAO é responsável por fazer a comunicação entre a aplicação e os dados fisicamente. Por exemplo, se nossos dados estão gravados em um S.G.B.D é responsabilidade do DAO, saber como vai se comunicar com o S.G.B.D e como irá manipular esses os dados. Estabelecer a conexão, enviar os dados o S.G.B.D, recuperar os dados retornados, são todas funções do DAO. No caso do S.G.B.D, utilizamos SQL para manipular dados, essa é o protocolo utilizado para a comunicação entre a aplicação e o S.G.B.D, saber esse protocolo também é responsabilidade do DAO.

Agora suponha que utilizaremos um X.M.L para armazenar nossos dados. Novamente é responsabilidade do DAO, saber o protocolo de comunicação, a forma de estabelecer a comunicação com o arquivo, como manipular os dados os dados, recuperar os dados retornados, interpretar mensagens de erro.

Se passar a utilizar um Web Service, um arquivo TXT, um S.G.B.D No SQL, ou qualquer outra forma de armazenamento de dados, o DAO continua tendo todas as atribuições citadas anteriormente. Já o repositório não tem essas atribuições.

O repositório é inerente ao domínio, sabe apenas sobre o domínio, não sabe como os dados serão armazenados ou recuperados, ou onde eles estão.

Por exemplo, em nosso aplicação temos uma entidade pessoa, para consultar apenas pessoas com mais de 18 anos utilizando um DAO faríamos da seguinte maneira:

public class PessoaDAO{
    public Pessoa consultarMaiorIdade(){
        String sql = "SELECT * FROM pessoa WHERE idade >= 18";
        ResultSet rs = con.prepareStatement(sql);
        ...
        return pessoa;
    }
}

Neste trecho de código pode ser observado que o DAO é responsável por todos os aspectos citados acima.

Abaixo está como o repositório se comporta nesta mesma situação:

public class PessoaRepositorio{
    public Pessoa consultarMaiorIdade(){
        QuerieObject qo = new QuerieObject();
        qo.setEntidade(Pessoa.class);
        qo.setFiltro("idade >= 18");

        return domainStore.consultar(qo);
    }
}

Como pode ser visto estamos fazendo uso de dois outros padrões QuerieObject e DomainStore, é não é escopo deste post a explicação destes padrões. Mas apenas como uma referencia o objeto Criteria do hibernate é um QuerieObject e o Hibernate um DomainStore.

Como vimos o repositorio não tem nada responsabilidades como o DAO. Isso por que ele deve saber apenas sobre o domínio, veja que não existe conexão com banco de dados ou qualquer outro código que não seja referente ao domínio.

Como o domínio deve ser blindado e o repositório faz parte do domínio, então este também não pode sofrer interferências de infraestrutura, ou da forma de armamento de dados. O que temos aqui é um QuerieObject para onde são passados os filtros que devem ser consultados, mas que não define como essa consulta será feita. Isso torna o repositório blindado, se trocarmos a fonte de dados para um XML, TXT ou qualquer outra fonte, não terá reflexo algum no repositório, pois, o repositório não trata essas questões, isso passa a ser responsabilidade do domain store ou do DAO.

Podemos utilizar um DAO no lugar de um DomainStore. Podermos utilizar Repositório e DAO juntos. Sendo assim o DAO será responsável por fazer toda a parte de infraestrutura.