Qual é a diferença entre o mapeador de dados, Tabela gateway de dados (gateway), Data Access Object (DAO) e padrões de repositório?

StackOverflow https://stackoverflow.com/questions/804751

Pergunta

Eu estou tentando escovar acima em minhas habilidades padrão de design, e estou curioso quais são as diferenças entre esses padrões? Todos eles parece que eles são a mesma coisa - encapsular a lógica de banco de dados para uma entidade específica para que o código de chamada não tem conhecimento da camada de persistência subjacente. Da minha breve pesquisa todos eles tipicamente implementar seus métodos CRUD padrão e separar os detalhes específicos do banco de dados.

Além de convenções de nomenclatura (por exemplo CustomerMapper vs. CustomerDAO vs. CustomerGateway vs. CustomerRepository), qual é a diferença, se houver? Se houver uma diferença, quando você escolheria um sobre o outro?

No passado, eu iria escrever um código semelhante ao seguinte (simplificado, naturalmente - Eu não usaria normalmente propriedades públicas): 

public class Customer
{
    public long ID;
    public string FirstName;
    public string LastName;
    public string CompanyName;
}

public interface ICustomerGateway
{
    IList<Customer> GetAll();
    Customer GetCustomerByID(long id);
    bool AddNewCustomer(Customer customer);
    bool UpdateCustomer(Customer customer);
    bool DeleteCustomer(long id);
}

e ter uma classe CustomerGateway que implementa a lógica de banco de dados específico para todos os métodos. Às vezes eu não iria usar uma interface e fazer todos os métodos no estática CustomerGateway (Eu sei, eu sei, que o torna menos testável) para que eu possa chamá-lo assim: 

Customer cust = CustomerGateway.GetCustomerByID(42);

Este parece ser o mesmo princípio para o mapeador de dados e padrões de repositório; o padrão DAO (que é a mesma coisa que Gateway, eu acho?) também parece encorajar gateways específicos de banco de dados.

Estou faltando alguma coisa? Parece um pouco estranho ter 3-4 maneiras diferentes de fazer a mesma coisa exata.

Foi útil?

Solução

Seus exemplos termos; DataMapper, DAO, DataTableGateway and Repository, todos têm um propósito semelhante (quando eu uso um, espero voltar um objeto Cliente), mas diferente intenção / Significado e resultando implementação.

A Repositório "age como uma coleção, exceto com capacidade de consulta mais elaborada" [ Evans, Domain Driven projeto ] e pode ser considerado como um "objetos na fachada de memória" ( Repository discussão )

A DataMapper "move dados entre objetos e um banco de dados, mantendo-os independentes uns dos outros e do próprio mapeador" ( Fowler, PoEAA, Mapper )

A TableDataGateway "um Gateway (objeto que encapsula o acesso a um sistema externo ou recurso) a uma tabela de banco de dados. Uma instância lida com todas as linhas na tabela " ( Fowler, PoEAA, TableDataGateway )

A DAO "separa interface do cliente de um recurso de dados de seus mecanismos de acesso a dados / adapta API de acesso de um recurso de dados específico para uma interface do cliente genérico" permitindo " mecanismos de acesso de dados para alterar independentemente do código que usa os dados " ( Sun Blueprints )

Repository parece muito genérico, expondo nenhuma noção de interação com o banco. A DAO fornece uma interface permitindo que diferentes implementações de bancos de dados subjacentes para ser utilizado. Um TableDataGateway é especificamente um invólucro fino em torno de uma única tabela. Um DataMapper actua como um intermediário permitindo que o objecto do modelo de evoluir de forma independente do banco de dados de representação (ao longo do tempo).

Outras dicas

Há uma tendência no mundo de design de software (pelo menos, eu me sinto tão) para inventar novos nomes para as coisas e os velhos padrões bem conhecidos. E quando temos um novo paradigma (que talvez um pouco difere de coisas já existentes), que normalmente vem com um conjunto de novos nomes para cada camada. Assim, "Lógica de Negócios" torna-se "Layer Serviços" apenas porque dizemos que fazemos SOA, e DAO torna Repository só porque dizemos que fazemos DDD (e cada uma delas não é realmente algo novo e único em tudo, mas novamente: novos nomes para conceitos reunidos no mesmo livro já conhecido). Então, eu não estou dizendo que todos esses paradigmas modernos e siglas significam exatamente a mesma coisa, mas você realmente não deve ser muito paranóico com isso. Principalmente estes são os mesmos padrões, só a partir de diferentes famílias.

Data Mapper vs Table Data Gateway Para fazer uma longa história curta:

  • o Mapeador de Dados receberá o objeto Modelo de Domínio (Entity) como param e vai usá-lo para implementar as operações CRUD
  • Tabela de Dados Gateway recebe todos os parâmetros (como primitivos) para os métodos e não sabe nada sobre o objeto Modelo de Domínio (Entity).

    No final ambos atuará como mediador entre os objetos em memória e banco de dados.

    • Você tem um bom ponto. Escolha o que você está mais familiarizado. Eu gostaria de salientar algumas coisas que podem ajudar a esclarecer.

    O Quadro de Dados Gateway é usada principalmente para uma única tabela ou vista. Ele contém todos os seleciona, inserções, atualizações e exclusões. Então cliente é uma tabela ou uma vista no seu caso. Assim, uma instância de um objeto de gateway de dados de tabela lida com todas as linhas na tabela. Geralmente isso está relacionado a um objeto por tabela de banco de dados.

    Enquanto Data Mapper é mais independente de qualquer lógica de domínio e é menos acoplado (embora eu acredite ou não há acoplamento ou não acoplamento). É apenas uma camada intermediária para transferir os dados entre os objetos e um banco de dados, mantendo-os independentes uns dos outros e do próprio mapeador.

    Assim, tipicamente em um mapeador, você vê métodos como insert, update, delete e em dados da tabela porta de entrada você vai encontrar getcustomerbyId, getcustomerbyName, etc.

    difere objeto de transferência de dados a partir do acima de dois padrões, principalmente porque é um padrão de distribuição e não um padrão de fonte de dados como acima dois padrões. Usá-lo principalmente quando você está trabalhando com a interface remota e necessidade de fazer suas chamadas menos falador como cada chamada pode sair caro. Por isso, normalmente projetar um DTO que pode ser serializado sobre o fio que pode transportar toda a parte de trás de dados para o servidor para aplicar novas regras ou processamento de negócios.

    Eu não estou bem versado em padrão de repositório como eu não tive a chance de usar até agora, mas vai estar a olhar para outras respostas.

    A seguir é apenas a minha compreensão.

    TableGateWay / RowDataGateWay : Neste contexto, o Gateway está a referir uma implementação específica que tem cada mapeamento "objeto de domínio" para cada "porta de entrada objeto de domínio". Por exemplo, se temos Person , então teremos um PersonGateway para armazenar o objeto de domínio Pessoa de banco de dados. Se tivermos Pessoa, funcionário, cliente, etc, teremos PersonGateway, EmployeeGateway e CustomerGateway. Cada gateway terá função CRUD específica para esse objeto e não tem nada a ver com outro gateway. Não há reutilizáveis ??de código / módulo aqui. O gateway pode ser dividida em RowDataGateway ou TableGateway, depende se você passar um "id" ou um "objeto". Gateway é geralmente comparada com registro ativo. Ele amarra seu modelo de domínio de esquema de banco de dados.

    Repository / DataMapper / DAO : Eles são a mesma coisa. Todos eles referem-se a camada de persistência que as entidades do banco de dados de transferência de modelo de domínio. Ao contrário de gateway, a ocultar Repositório / DataMapper / DAO a aplicação. Você não sabe se há uma PersonGateway trás Pessoa. Ele pode, ou não pode, você não se importa. Tudo o que sei é que deve ter operações CRUD suportados para cada objeto de domínio. Ele dissociar o modelo de fonte de dados e domínio.

    Licenciado em: CC-BY-SA com atribuição
    Não afiliado a StackOverflow
    scroll top