Estou tentando aprimorar minhas habilidades de padrão de design e estou curioso para saber quais são as diferenças entre esses padrões. Todos eles parecem ser a mesma coisa - encapsula a lógica do banco de dados para uma entidade específica, para que o código de chamada não tenha conhecimento da camada de persistência subjacente. De minha breve pesquisa, todos eles geralmente implementam seus métodos CRUD padrão e abstraem os detalhes específicos do banco de dados.
Além das 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 uma sobre a outra?
No passado, eu escrevia um código semelhante ao seguinte (simplificado, naturalmente - eu normalmente não usaria 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 tem uma CustomerGatewayclasse que implementa a lógica específica do banco de dados para todos os métodos. Às vezes, eu não usava uma interface e tornava estáticos todos os métodos no CustomerGateway (eu sei, isso o torna menos testável), para que eu possa chamá-lo assim:
Customer cust = CustomerGateway.GetCustomerByID(42);Esse parece ser o mesmo princípio para os padrões Data Mapper e Repository; o padrão DAO (que é a mesma coisa que Gateway, eu acho?) também parece incentivar gateways específicos do banco de dados.
Estou esquecendo de algo? Parece um pouco estranho ter 3-4 maneiras diferentes de fazer a mesma coisa.
fonte
Existe uma tendência no mundo do design de software (pelo menos eu acho) de inventar novos nomes para coisas e padrões antigos bem conhecidos. E quando temos um novo paradigma (que talvez seja um pouco diferente das coisas já existentes), geralmente ele vem com um conjunto inteiro de novos nomes para cada camada. Assim, "Business Logic" se torna "Services Layer" apenas porque dizemos que fazemos SOA, e o DAO se torna Repositório apenas porque dizemos que fazemos DDD (e cada um deles não é realmente algo novo e único, mas novamente: novos nomes para conceitos já conhecidos reunidos no mesmo livro). Portanto, não estou dizendo que todos esses paradigmas e siglas modernos significam EXATAMENTE a mesma coisa, mas você realmente não deveria estar muito paranóico com isso. Principalmente esses são os mesmos padrões, apenas de famílias diferentes.
fonte
Data Mapper vs Table Data Gateway Para resumir uma longa história:
No final, os dois atuarão como mediadores entre os objetos na memória e o banco de dados.
fonte
Você tem um bom argumento. Escolha o que você está mais familiarizado. Eu gosto de apontar algumas coisas que podem ajudar a esclarecer.
O Gateway de dados da tabela é usado principalmente para uma única tabela ou exibição. Ele contém todas as seleções, inserções, atualizações e exclusões. Portanto, o Cliente é uma tabela ou uma visualização no seu caso. Portanto, uma instância de um objeto de gateway de dados da tabela lida com todas as linhas da tabela. Geralmente, isso está relacionado a um objeto por tabela do banco de dados.
Enquanto o Data Mapper é mais independente de qualquer lógica de domínio e é menos acoplado (embora eu acredite que haja ou não acoplamento). É apenas uma camada intermediária para transferir os dados entre objetos e um banco de dados, mantendo-os independentes um do outro e do próprio mapeador.
Portanto, normalmente em um mapeador, você vê métodos como inserir, atualizar, excluir e, no gateway de dados da tabela, encontrará getcustomerbyId, getcustomerbyName, etc.
O objeto de transferência de dados difere dos dois padrões acima, principalmente porque é um padrão de distribuição e não um padrão de fonte de dados como acima dos dois padrões. Use-o principalmente quando estiver trabalhando com interface remota e precisar tornar suas chamadas menos tagarelas, pois cada chamada pode ficar cara. Por isso, geralmente projete um DTO que possa ser serializado por fio que possa transportar todos os dados de volta ao servidor para aplicar outras regras ou processamento de negócios.
Não sou muito versado no padrão de repositório, pois não tive a chance de usá-lo até agora, mas estarei olhando para as respostas de outras pessoas.
fonte
Abaixo está apenas o meu entendimento.
TableGateWay / RowDataGateWay : nesse contexto, o Gateway está se referindo a uma implementação específica que tem cada "objeto de domínio" mapeado para cada "gateway de objeto de domínio". Por exemplo, se tivermos Person , teremos um PersonGateway para armazenar o objeto de domínio Person no banco de dados. Se tivermos Pessoa, Funcionário, Cliente, etc., teremos PersonGateway, EmployeeGateway e CustomerGateway. Cada gateway terá uma função CRUD específica para esse objeto e não tem nada a ver com outro gateway. Não há código / módulo reutilizável aqui. O gateway pode ser dividido em RowDataGateway ou TableGateway, depende se você passar um "id" ou um "objeto". O gateway geralmente é comparado ao registro ativo. Ele vincula seu modelo de domínio ao esquema do banco de dados.
Repositório / DataMapper / DAO : Eles são a mesma coisa. Todos eles se referem à camada Persistência que transfere entidades do banco de dados para o modelo de domínio. Ao contrário do gateway, o Repositório / DataMapper / DAO oculta a implementação. Você não sabe se existe uma PersonGateway atrás da Person. Pode ou não, você não se importa. Tudo que você sabe é que deve haver operações CRUD suportadas para cada objeto de domínio. Ele desacopla a fonte de dados e o modelo de domínio.
fonte