Um dos padr\u00f5es mais utilizados quando usamos DDD, mesmo que seu projeto use um DDD meio falsificado, \u00e9 o Repository Pattern e em alguns casos em conjunto com Unit Of Work. Existem varias implementa\u00e7\u00f5es desses padr\u00f5es, no qual eu concordo com algumas e descordo de outras.
Lembre – se, padr\u00f5es foram feitos para resolver problemas existentes, se voc\u00ea tem um problema novo, fa\u00e7a algo novo!<\/p>\n\n\n\n
Segundo Eric Evans: <\/p>\n\n\n\n
\n“Um reposit\u00f3rio representa todos os objetos de um determinado tipo como sendo um conjunto conceitual (normalmente imitado). Ele age como uma cole\u00e7\u00e3o. Objetos do tipo adequado s\u00e3o acrescentados ou removidos e o maquin\u00e1rio existente por tr\u00e1s do reposit\u00f3rio os insere ou os exclui do banco de dados. Essa defini\u00e7\u00e3o une um conjunto coeso de responsabilidades para fornecer acesso as raizes de agrega\u00e7\u00e3o desde o inicio do ciclo de vida ate o seu final.” [DDD, Evans, p: 143]<\/p>\n<\/blockquote>\n\n\n\n
Segundo Vernon:<\/p>\n\n\n\n
\n\u201cUm reposit\u00f3rio comumente se refere a um local de armazenamento, geralmente considerado um lugar de seguran\u00e7a ou preserva\u00e7\u00e3o dos itens armazenados nele. Ao armazenar algo em um reposit\u00f3rio e depois retornar para recupera – lo, espera – se que ele estar\u00e1 no mesmo estado em que se encontrava quando voc\u00ea o colocou la.\u201d [DDD, Vernon, p: 401]<\/p>\n<\/blockquote>\n\n\n\n
Segundo Dumb\u00e1:<\/p>\n\n\n\n
\n\u201cUm reposit\u00f3rio \u00e9 simplesmente o lugar onde voc\u00ea vai guardar e recuperar as informa\u00e7\u00f5es do seu objeto. Sendo ele sua raiz de agrega\u00e7\u00e3o. \u201d \ud83d\ude42 <\/p>\n<\/blockquote>\n\n\n\n
Quem pensou que seria onde voc\u00ea faz o CRUD, os puritanos v\u00e3o me matar, mas \u00e9 exatamente isso! Mas, todavia, entretanto, com algumas particularidades. O reposit\u00f3rio deve representar em mem\u00f3ria a persist\u00eancia do o seu objeto, seja ele em banco de dados, TXT, papel de p\u00e3o ou embaixo da cadeira. <\/p>\n\n\n\n
Lembrando que se voc\u00ea enche seu reposit\u00f3rio de consultas para filtros ou relat\u00f3rios, possivelmente ter\u00e1 um outro padr\u00e3o chamado DAO, \u201cData Access Object\u201d. Isso pode ser representado em outro lugar. Veja o Estilo CQRS por exemplo (Esse video \u00e9 perfeito sobre o assunto<\/a>). <\/em><\/p>\n\n\n\n
Mas Dumb\u00e1, eu coloco todas as minhas Queries no reposit\u00f3rio e retorno meus DTOs, estou errado??
<\/strong>Errado voc\u00ea n\u00e3o est\u00e1, mas tamb\u00e9m n\u00e3o esta certo. Como diz o outro: \u201cSe funciona e porque esta certo\u201d \ud83d\ude42<\/p>\n\n\n\nMas porque eu n\u00e3o gosto disso? <\/p>\n\n\n\n
Por que geralmente o reposit\u00f3rio ira representar sua Raiz de Agrega\u00e7\u00e3o (AggragateRoot) e ele, na teoria, teria somente os m\u00e9todos Create, Update, GetByID e Delete, alguns ainda colocam o Count.
Ent\u00e3o o reposit\u00f3rio representa o famoso CRUD!!!?? Calma!<\/strong>
Na verdade, voc\u00ea pode sim colocar um retorno de uma cole\u00e7\u00e3o do seu objeto, lembrando que o objeto deve ser de sua Raiz de Agrega\u00e7\u00e3o. Se eu entupo ele de selects ate mesmo enxugar um objeto, possivelmente isso seria o caso de retornar um DTO e n\u00e3o o meu objeto em especifico. Te aconselho a fazer de uma outra forma. Lembre – se do CQRS.<\/p>\n\n\n\nMas posso ter DTO com Repository?
<\/strong>Sim, mas n\u00e3o no seu reposit\u00f3rio, de preferencia. Crie um \u201cQuerieRepository” para voc\u00ea nao ficar triste. <\/p>\n\n\n\nExemplos:<\/h4>\n\n\n\n
Interface de um repository:<\/p>\n\n\n\n
public abstract class Repository<T, TId> where T : AggregateRoot<TId>\n {\n protected DbSet<T> _dbSet;\n\n protected Repository(DbContext context)\n {\n _dbSet = context.Set<T>();\n }\n\n public virtual void Create(T entity)\n {\n _dbSet.Add(entity);\n }\n\n public virtual void Update(T entity)\n {\n _dbSet.Update(entity);\n }\n\n public virtual T GetByID(TId id)\n {\n return _dbSet.FirstOrDefault(x => x.Id.Equals(id));\n }\n\n public virtual void Remove(T entity)\n {\n _dbSet.Remove(entity);\n }\n }<\/pre>\n\n\n\nInterface de um “QueryRepository”<\/p>\n\n\n\n
public abstract class QueryRepository\n{\n readonly DbContext _context;\n protected QueryRepository(DbContext context)\n {\n _context = context;\n }\n\n \/\/\/ <summary>\n \/\/\/ Faz o select em seu banco de dados usando o LINQ do Entity Framework (EF)\n \/\/\/ <\/summary>\n \/\/\/ <typeparam name=\"TEntity\">Sua classe de entidade<\/typeparam>\n protected IEnumerable<TEntity> SelectLinq<TEntity>(Func<TEntity, bool> predicate) where TEntity: class\n {\n return _context.Set<TEntity>().Where(predicate);\n }\n\n \/\/\/ <summary>\n \/\/\/ Faz o select em seu banco de dados\n \/\/\/ <\/summary>\n \/\/\/ <typeparam name=\"Tdto\"><\/typeparam>\n protected IList<Tdto> SelectSql<Tdto>(string sql, params object[] parameters) where Tdto: class\n {\n using var command = _context.Database.GetDbConnection().CreateCommand();\n command.CommandText = sql;\n\n foreach (var parameter in parameters)\n {\n command.Parameters.Add(parameter);\n }\n\n _context.Database.OpenConnection();\n using var result = command.ExecuteReader();\n return DataReaderMapToList<Tdto>(result);\n }\n\n private static List<Tdto> DataReaderMapToList<Tdto>(DbDataReader dr)\n {\n List<Tdto> list = new List<Tdto>();\n\n if (dr.HasRows)\n {\n while (dr.Read())\n {\n var dto = Activator.CreateInstance<Tdto>();\n foreach (PropertyInfo prop in dto.GetType().GetProperties())\n {\n if (dr.GetColumnSchema().Any(x => x.ColumnName.ToUpper() == prop.Name.ToUpper()))\n {\n if (!Equals(dr[prop.Name], DBNull.Value))\n {\n prop.SetValue(dto, dr[prop.Name], null);\n }\n }\n }\n list.Add(dto);\n }\n return list;\n }\n return new List<Tdto>();\n }\n}<\/pre>\n\n\n\nUnit Of Work<\/h2>\n\n\n\n
A grande resolu\u00e7\u00e3o de problemas deste padr\u00e3o se da para a resposta a pergunta:<\/p>\n\n\n\n
Muito bom o reposit\u00f3rio, mas como eu controlo um contexto transacional em duas raizes de agrega\u00e7\u00e3o? \u00c9 ai que o unit of work entra com os quatro p\u00e9 na porta!<\/em><\/p>\n\n\n\n
Segundo Fowler em seu site:<\/p>\n\n\n\n
\n\u201cUma Unit of Work, mant\u00e9m uma lista de objetos afetados por uma transa\u00e7\u00e3o comercial e coordena a grava\u00e7\u00e3o de altera\u00e7\u00f5es e a resolu\u00e7\u00e3o de problemas de simultaneidade.”<\/p>\n<\/blockquote>\n\n\n\n
Ele funciona como um controle de transa\u00e7\u00f5es entre os reposit\u00f3rios, como uma transa\u00e7\u00e3o de banco de dados, sim puritanos \u00e9 o melhor exemplo de compara\u00e7\u00e3o, mas lembre – se que nada \u00e9 t\u00e3o simples quanto parece, pois tudo isso deve servir n\u00e3o somente para banco de dados, mas para qualquer meio que persista seu objeto.
\u00c9 aqui que vejo enumeras implementa\u00e7\u00f5es diferentes. Erradas? N\u00e3o!! Mas tenho menos afinidades com algumas que vou explicar o porque. <\/p>\n\n\n\nPara quem n\u00e3o sabe, o Entity Framework e o NHibernate ja implementam esse padr\u00e3o de projetos em conjunto com o Repository. <\/p>\n\n\n\n
Mas Dumb\u00e1, ja utilizo o Entity nos meus projetos, ent\u00e3o porque vou reinventar a roda?
<\/strong>Voc\u00ea vai fazer isso porque n\u00e3o quer o seu projeto fortemente acoplado com um framework e \u00e9 um Dev esperto ja que est\u00e1 lendo esse artigo. <\/p>\n\n\n\nUma dica \u00e9 que todos esses padr\u00f5es e estilos arquiteturais escritos no mundo tem somente um objetivo em comum, o Desacoplamento<\/strong>. Assunto para um pr\u00f3ximo artigo.<\/em><\/p>\n\n\n\n
Usando o exemplo do Entity, o seu DBContext seria sua UnitOfWork e seus DBSets seriam os seus reposit\u00f3rios.
Esse \u00e9 o modelo mais divulgado, mas no meu ponto de vista o mais mal implementado. Ele funciona muito bem quando temos mapas de contextos muito bem definidos nos projetos e n\u00e3o um sistema com um \u00fanico Unit Of Work e 3856 reposit\u00f3rios. <\/p>\n\n\n\n[av_image src=’http:\/\/dsdumba.com\/wp-content\/uploads\/2021\/10\/UnitOfWork1.png’ attachment=’273′ attachment_size=’full’ copyright=” caption=” styling=” align=’center’ font_size=” overlay_opacity=’0.4′ overlay_color=’#000000′ overlay_text_color=’#ffffff’ animation=’no-animation’ hover=” appearance=” link=” target=” id=” custom_class=” av_element_hidden_in_editor=’0′ av_uid=’av-acryn’ admin_preview_bg=”][\/av_image]<\/p>\n\n\n\n
[av_image src=’http:\/\/dsdumba.com\/wp-content\/uploads\/2021\/10\/UnitOfWork2.jpg’ attachment=’274′ attachment_size=’full’ copyright=” caption=” styling=” align=’center’ font_size=” overlay_opacity=’0.4′ overlay_color=’#000000′ overlay_text_color=’#ffffff’ animation=’no-animation’ hover=” appearance=” link=” target=” id=” custom_class=” av_element_hidden_in_editor=’0′ av_uid=’av-8c82v’ admin_preview_bg=”][\/av_image]<\/p>\n\n\n\n
public class UnitOfWork\n{\n IRepository1 Repository1 { get { return new Repository1(); } }\n IRepository2 Repository2 { get { return new Repository2(); } }\n IRepositoryN RepositoryN { get { return new RepositoryN(); } }\n void Commit() {}\n void Rollback() {}\n}<\/pre>\n\n\n\nNessa implementa\u00e7\u00e3o, temos uma classe de UnitOfWork que comp\u00f5em todas as classes do seu contexto de reposit\u00f3rio. Assim qualquer chamada de reposit\u00f3rio para seu objeto passa necessariamente pela sua UnitOfWork. <\/p>\n\n\n\n
Pontos que n\u00e3o gosto. <\/p>\n\n\n\n
\n
- Na maioria das vezes temos um contexto com 3978 reposit\u00f3rios mapeados na Unit Of Work, pois na grande maioria das empresas somente trabalha com um contexto. \u201cDDD meio doente\u201d<\/li>\n\n\n\n
- Forte acoplamento, pois para cada chamada de Get ter\u00edamos uma constru\u00e7\u00e3o da classe de reposit\u00f3rio.\u00a0<\/li>\n\n\n\n
- Testabilidade. Acho que nem sei como testar um negocio desse. \ud83d\ude42\u00a0<\/li>\n\n\n\n
- E pra mim, muito pra mim, ele fere o principio da responsabilidade \u00fanica, pois na minha interpreta\u00e7\u00e3o a UnitOfWork deveria somente controlar a persist\u00eancia e n\u00e3o os reposit\u00f3rios, mas isso \u00e9 a minha opini\u00e3o.\u00a0<\/li>\n<\/ul>\n\n\n\n
Uma outra implementa\u00e7\u00e3o seria a mesma citada acima, porem com a inje\u00e7\u00e3o de depend\u00eancia dos reposit\u00f3rios, melhorando a Testabilidade e o forte Acoplamento. Mas acrescento o Overhead de mem\u00f3ria. Imagine ter instanciando 3000 reposit\u00f3rios ao usar a Unit Of Work?<\/p>\n\n\n\n
public class UnitOfWork\n{\n public readonly IRepository1 _repository1;\n public readonly IRepository2 _repository2;\n public readonly IRepositoryN _repository3;\n\n public UnitOfWork(IRepository1 repository1,\n IRepository2 repository2,\n IRepositoryN repository3)\n {\n _repository1 = repository1;\n _repository2 = repository2;\n _repository3 = repository3;\n }\n\n void Commit() {}\n void Rollback() {}\n}<\/pre>\n\n\n\nUma outra seria tamb\u00e9m muito parecida, por\u00e9m recuperada por Service Locator. Nesse ponto ate gosto mais, pois ai fica somente a minha particularidade da Responsabilidade \u00danica do SOLID, mas ai entra o Service Locator que n\u00e3o me simpatizo muito com ele, outra opini\u00e3o minha e somente minha. Mas cabe aqui um outro artigo.<\/p>\n\n\n\n
[av_image src=’http:\/\/dsdumba.com\/wp-content\/uploads\/2021\/10\/UnitOfWork3.jpg’ attachment=’275′ attachment_size=’full’ copyright=” caption=” styling=” align=’center’ font_size=” overlay_opacity=’0.4′ overlay_color=’#000000′ overlay_text_color=’#ffffff’ animation=’no-animation’ hover=” appearance=” link=” target=” id=” custom_class=” av_element_hidden_in_editor=’0′ av_uid=’av-15s2f’ admin_preview_bg=”][\/av_image]<\/p>\n\n\n\n
public class UnitOfWork\n{\n IRepository GetRepository<TRepository>() where TRepository: IRepository\n {\n \/\/Implemente seu ServiceLocator.\n }\n void Commit() {}\n void Rollback() {}\n}\n<\/pre>\n\n\n\nLembrando que tudo isso pode ser minimizado utilizando os mapas de contextos de forma correta, pois assim o projeto n\u00e3o teria uma \u00fanica UnitOfWork somente, mas uma por contexto.<\/em><\/p>\n\n\n\n
Eu ja prefiro fazer de forma separada. Cada um no seu quadrado. <\/p>\n\n\n\n
[av_image src=’http:\/\/dsdumba.com\/wp-content\/uploads\/2021\/10\/UnitOfWork4-300×238.jpg’ attachment=’276′ attachment_size=’medium’ copyright=” caption=” styling=” align=’center’ font_size=” overlay_opacity=’0.4′ overlay_color=’#000000′ overlay_text_color=’#ffffff’ animation=’no-animation’ hover=” appearance=” link=” target=” id=” custom_class=” av_element_hidden_in_editor=’0′ av_uid=’av-b3ean’ admin_preview_bg=”][\/av_image]<\/p>\n\n\n\n
Dessa forma, tenho um \u201cDbConnection” que pode ser sua implementa\u00e7\u00e3o para banco de dados (dbContext por exemplo), TXT, Papel de P\u00e3o, etc. Na implementa\u00e7\u00e3o da UnitOfWork e do Repository, temos uma composi\u00e7\u00e3o da classe DbConnection. Como nas duas classes temos a mesma instancia de DbConnection, temos o controle transacional. Assim passo a UnitOfWork e somente os reposit\u00f3rios que desejo trabalhar evitando todos os problemas relatados anteriormente.<\/p>\n\n\n\n
public class CreateLogCommandHandler : CommandHandler<CreateLogCommand, Guid>\n{\n readonly ILogRepository _logRepository;\n readonly IProjectRepository _projectRepository;\n public CreateLogCommandHandler(\n IValidationService validationService,\n IUnitOfWork uow,\n ILogRepository logRepository,\n IProjectRepository projectRepository) : base(validationService, uow)\n {\n _logRepository = logRepository;\n _projectRepository = projectRepository;\n }\n\n public override async Task<Guid> Handle(CreateLogCommand request, CancellationToken cancellationToken)\n {\n if (!this.IsValidCommand(request))\n {\n return await Task.FromResult(Guid.Empty);\n }\n\n try\n {\n var project = _projectRepository.GetByApiKey(request.ApiKey);\n if (project == null)\n {\n _validationService.AddErrors(\"01\", \"Projeto nao encontrado para a api-key informada.\");\n return await Task.FromResult(Guid.Empty);\n }\n\n var log = new Log(request.Description, request.Source, request.LogType, project);\n\n await _logRepository.CreateAsync(log);\n await _uow.CommitAsync();\n\n return log.Id;\n }\n catch (DomainException ex)\n {\n _validationService.AddErrors(\"02\", ex.Message);\n return await Task.FromResult(Guid.Empty);\n }\n }\n}<\/pre>\n\n\n\nO que gosto \u00e9 o certo??
<\/strong>Pra alguns sim, para outros n\u00e3o, mas o importante e n\u00e3o se prender.<\/p>\n\n\n\nDumb\u00e1, n\u00e3o preciso controlar transa\u00e7\u00f5es de reposit\u00f3rios diferentes.
<\/strong>Ent\u00e3o coloque um m\u00e9todo de Commit no seu reposit\u00f3rio de n\u00e3o utilize o Unit Of Work.<\/p>\n\n\n\nNo meu GitHub<\/a> vai encontrar como eu utilizo esse padr\u00f5es nesse projeto<\/a>. Duvidas e sugest\u00f5es \u00e9 s\u00f3 mandar!!<\/p>\n\n\n\n
Lembre – se que nem eu, nem ningu\u00e9m al\u00e9m de voc\u00ea entende o seu contexto de desenvolvimento. Bom c\u00f3digo n\u00e3o significa que voc\u00ea colocou todo os padr\u00f5es do mundo nele. Bom c\u00f3digo, no meu ponto de vista, \u00e9 o que resolve o problema do seu cliente, que seja capaz de evoluir e que qualquer um consiga manter. Pense nisso. <\/p>\n\n\n\n
Bibliografia<\/h2>\n\n\n\n
https:\/\/martinfowler.com\/eaaCatalog\/unitOfWork.html<\/a>
http:\/\/www.macoratti.net\/16\/01\/net_uow1.htm<\/a>
https:\/\/www.devmedia.com.br\/unit-of-work-o-padrao-de-unidade-de-trabalho-net\/25811<\/a>
https:\/\/www.youtube.com\/watch?v=DZZSmllmydc<\/a>
https:\/\/www.youtube.com\/watch?v=FeqpZ9w-CRA<\/a>
https:\/\/docs.microsoft.com\/pt-br\/aspnet\/mvc\/overview\/older-versions\/getting-started-with-ef-5-using-mvc-4\/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application<\/a>
https:\/\/balta.io\/blog\/dapper-unit-of-work-repository-pattern<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"Um dos padr\u00f5es mais utilizados quando usamos DDD, mesmo que seu projeto use um DDD meio falsificado, \u00e9 o Repository Pattern e em alguns casos em conjunto com Unit Of Work. Existem varias implementa\u00e7\u00f5es desses padr\u00f5es, no qual eu concordo com algumas e descordo de outras.Lembre – se, padr\u00f5es foram feitos para resolver problemas existentes, […]<\/p>\n","protected":false},"author":1,"featured_media":71,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-70","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-arquitetura"],"_links":{"self":[{"href":"https:\/\/dumba.dev.br\/index.php\/wp-json\/wp\/v2\/posts\/70","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dumba.dev.br\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dumba.dev.br\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dumba.dev.br\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dumba.dev.br\/index.php\/wp-json\/wp\/v2\/comments?post=70"}],"version-history":[{"count":1,"href":"https:\/\/dumba.dev.br\/index.php\/wp-json\/wp\/v2\/posts\/70\/revisions"}],"predecessor-version":[{"id":72,"href":"https:\/\/dumba.dev.br\/index.php\/wp-json\/wp\/v2\/posts\/70\/revisions\/72"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dumba.dev.br\/index.php\/wp-json\/wp\/v2\/media\/71"}],"wp:attachment":[{"href":"https:\/\/dumba.dev.br\/index.php\/wp-json\/wp\/v2\/media?parent=70"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dumba.dev.br\/index.php\/wp-json\/wp\/v2\/categories?post=70"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dumba.dev.br\/index.php\/wp-json\/wp\/v2\/tags?post=70"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}