16
loading...
Evite o padrão de repositório para operações não relacionadas à persistência
English version available here.
Hoje quero compartilhar um pouco sobre o padrão Repositório e Fachada. Tentarei explicar suas diferenças, pois parece haver alguns equívocos comuns sobre eles.
Vamos tentar definir um repositório, a partir do dicionário: um lugar, sala ou contêiner onde algo é depositado ou armazenado. Em termos de programação, o conceito pode ser definido como uma classe responsável por lidar com operações CRUD (criar, ler, atualizar e deletar) para um modelo de domínio específico por meio do uso de uma ou mais fontes de dados.
Pela definição acima, podemos ver que devemos usar repositórios apenas para operações CRUD, o que significa que podemos ter um
UserRepository e nunca umAuthenticationRepository, simplesmente porque a autenticação não descreve um conjunto de operações CRUD (assumindo que estamos falando sobre operações de login/registro).Um erro comum que tenho visto é que algumas pessoas definem repositórios para operações de acesso ao sistema por exemplo:
abstract class AuthenticationRepository {
Future login(String username, String password);
Future register(String name, String email, String password);
}Claramente, essas não são operações para armazenar/recuperar dados e, portanto, nunca devemos declará-las em um repositório. E agora? Fachadas!
Pela Wikipedia, podemos definir uma fachada como um objeto que serve como uma interface frontal mascarando um código subjacente mais complexo.
Agora vamos definir um repositório: um Repositório é um tipo de fachada especializada em mascarar/abstrair operações CRUD complexas especificamente entre fontes de dados.
Para comparar e contrastar, fachadas são mais gerais do que repositórios - eles podem ser usados para qualquer coisa diferente de persistência. Você pode usar fachadas para abstrair interações complexas em APIs de vários bancos. Por exemplo:
// Or BankOperationsFacade.
abstract class BankOperations {
Future payTelecomService(double amount, String cardId, String serviceId);
Future transfer(double amount, String senderId, String recipientId);
}
// Custom implementation for XBank interaction goes here.
class XBankOperations extends BankOperations { }
// Custom implementation for YBank interaction goes here.
class YBankBOperations extends BankOperations { }Vamos revisar o primeiro trecho de código apresentado em nosso artigo, mas, desta vez, iremos refatorar o nome da classe para ser algo mais significativo.
// Or any other meaningful name.
abstract class AuthenticationFacade {
Future login(String username, String password);
Future register(String name, String email, String password);
}É importante fazer uso desses conceitos de maneira adequada para evitar escrever códigos difíceis de entender e para manter uma base de código saudável.
Espero que isso ajude você de alguma forma; por favor, deixe-me saber sua opinião na seção de comentários.
16