O repositório deve ter um método para cada operação de banco de dados específica?

Question

O repositório deve ter um método para cada operação de banco de dados específica?

#1 resposta do (2 votos)
#2 resposta do (0 votos)

5

Ao seguir os padrões de serviço e repositório padrão, seu repositório deve conter um método específico para cada operação de banco de dados ou você deve usar os métodos gerais, por exemplo, atualizar? Tomemos por exemplo o seguinte método de serviço:

DisableUser(User user) {
    user.enabled = false;
    userRepo.update(user); // General user update method
}

Isso realiza suas alterações no registro do usuário e, em seguida, solicita que o repositório atualize o banco de dados chamando o método geral de atualização do usuário.

Ou deveria ser mais específico, como:

DisableUser(User user) {
    userRepo.disable(user); // Specific operation, matching the service
}

Obviamente, este é um exemplo muito simples, mas eu sinto que a conclusão afeta a maneira como eu avanço com o repositório em geral e esta mesma lógica se aplica a muitos cenários.

O que mais me confunde é que, no primeiro caso, usar o método de atualização padrão pode ser visto como ineficiente, porque pode atualizar todas as colunas do registro, mas por acaso estou usando o Entity Framework para que ele possa verificar o que os campos mudaram e apenas atualizando o campo alterado para mim. Mas eu deveria estar fazendo essa suposição do meu serviço?

Se eu fosse escrever uma implementação de sql simples alternativa do id do repositório, teria que atualizar todos os campos lá, ou implementar a detecção de mudança de campo eu mesmo. Então essa parte me inclina para a implementação específica, mas com isso estou adicionando muito mais métodos e talvez pareça um pouco desnecessário.

Então, em poucas palavras, seu repo deve ter os métodos padrão, update, insert, findById, findAll, delete. Ou deveria ter um método para cada operação de banco de dados específica, como procedimentos armazenados.

Há provavelmente várias outras considerações que não estou entendendo. Qualquer conselho seria apreciado.

design-patterns repository patterns-and-practices

por matthewrk 09.06.2016 / 18:18

fonte

2 respostas

Tags design-patterns repository patterns-and-practices

Núcleo funcional para projeto de sistema de elevador É desejável um sistema de eventos com reconhecimento de promessa?

score 2 · Answer 1

Para fornecer uma perspectiva diferente da resposta já existente, eu diria que depende .

O genérico é mais reutilizável, mas o domínio específico indica intenção e separa melhor seu modelo de domínio da escolha da persistência. Se você fizer

var user = repo.GetUser(id); user.Enabled = false; repo.Update(user);

Então o repositório não tem idéia do que está fazendo (o que pode ser uma coisa boa do ponto de vista da reutilização). Mas você também perdeu a possibilidade de lembrar a intenção da operação.

Se você fizer o domínio específico:

repo.DisableUser(id);

Primeiro, talvez você possa implementar seu repositório de maneira mais eficiente. Você pode não precisar fazer com que o usuário o desabilite - talvez você possa apenas fazer um UPDATE e acabar com isso. Além disso, você sabe o que está fazendo, então você pode optar por também adicionar uma boa mensagem de log em um log de auditoria ou algo similar no nível do repositório. Embora você ainda pudesse fazer auditoria do log com a versão mais genérica, você obteria uma entrada genérica de "cliente atualizado" em vez de uma entrada "cliente desativado" específica do domínio. Isso pode, em muitos casos, ser muito bom e valioso.

Isso é mais trabalho, e é por isso que, em geral, as pessoas usam a solução genérica porque ela é mais genérica e mais fácil de implementar. Mas não desconsidere o repositório específico do domínio como inutilizável ou ruim, a resposta é sempre depende .

score 0 · Answer 2

Se você mantiver os métodos mais gerais, atualizar, inserir, localizarById, localizarTudo, excluir, seu código provavelmente será mais reutilizável. Com isso, quero dizer que, em vez de escrever um método específico para cada cenário, você descobrirá que pode simplesmente expor os métodos mais gerais e usá-los para os casos específicos necessários. Por exemplo, talvez eu precise desativar um usuário, para isso eu chamaria o método de atualização. Posteriormente, você poderá ter outras interfaces que precisem desabilitar um usuário e poderá chamar novamente o mesmo método de atualização, em vez de escrever um método totalmente novo para lidar com esse caso específico. Eu fiz muito trabalho em SOA (Services Oriented Architecture) e posso dizer que quanto mais genérico você puder manter as coisas, mais fácil será encontrá-lo para manter um bom código. Eventualmente, você pode achar que sua organização deseja mover para um Barramento de Serviços para manter todos os vários serviços. Com métodos mais genéricos, esta transição será muito mais fácil.