ASP.NET Core APIs - Repository Pattern e Unit of Work | por André Baltieri

Blog: Injeção de Dependência no ASP.NET Core
balta.io/blog/...
--
Que tal dar aquele UP na sua carreira?
balta.io/carre...
Conheça também nossos cursos
balta.io/cursos
Participe do nosso grupo no Telegram
t.me/baltaio
Facebook
/ balta.io
Twitter
/ balta_io
LinkedIn
/ balta-io
GitHub
github.com/bal...
Instagram
/ balta.io

[@Diegolaquino]

Balta, você é um grande professor. Tanto no KZbin, quanto no seu site, seus conteúdos são excelentes. Essas explicações ao longo do conteúdo fazem total diferença.

[@baltaio]

Muito obrigado

[@PauloHinkel]

Gostaria de ter visto esse vídeo antes.. tive várias dificuldades para implementar esses conceitos.. Gratidão!! Abraços

[@vagnermello]

Fantástico! Curti muito mesmo. Nós percebemos sua preocupação em dizer o tempo todo que é uma implementação simples, que não se deve fazer isso ou aquilo... enfim, suas explicações são muito boas e acredito que explicar conceitos de forma simples é muito mais agradável de aprender. Muito obrigado! parabéns!

[@baltaio]

Muito obrigado

[@nao-enrola]

Balta explicou tudo falou q eh demo demo demo simples n eh codigo de producao. Mas teve gente q n entendeu. Mais claro q isso so se ele fechar a tarefa do cara q ta perdido na sprint. Rs.

[@henriquedetoni1433]

Excelente. Mesmo não conhecendo o C# deu pra entender bem. Você poderia fazer vídeos com temas de design patterns utilizando node? Valeu.

[@yurimatosrodrigues5337]

Parabéns e obrigado pelo conteúdo. Muito bom.

[@baltaio]

Eu que agradeço

[@juniorodrigues8198]

Que aula boa e completa. Valeu

[@baltaio]

Bons estudos!🚀🚀🚀

[@olucasromero]

Achei muito bom o vídeo, bem direto ao ponto. Ótimo conteúdo

[@thiagojorge8637]

Excelente vídeo, finalmente entendi o Uow e vi que não é um bicho de 7 cabeças!

[@baltaio]

wowwwwww hahahahah que bacana

[@michelplatini9212]

Ótimo conteúdo

[@slopesjoe]

Muito obrigado professor Balta! Excelente aula!

[@baltaio]

💜

[@awernek81]

Sempre contribuindo!!! Top

[@vgatti3694]

Show de bola!! Tava procurando sobre isso agora kkk obrigado por compartilhar

[@sauloalmeidadev]

Valeu pelo o conteúdo, Balta!

[@saulolima6874]

Obrigado Professor!

[@baltaio]

Bons estudos!

[@HernandesJunio]

Show de bola, parabéns!

[@rft13hk]

Balta, parabéns pelo video, segue uma dica de como você poderia implementar o RollBack, fazendo um Reset dos objetos alterados: public void RollBack() { ResetContextState(); } private void ResetContextState() => _context.ChangeTracker.Entries() .Where(e => e.Entity != null).ToList() .ForEach(e => e.State = EntityState.Detached);

[@xBalaDeCanhaox]

Vlw Balta curti demais o conteúdo. Tá favoritado!

[@SuperCharves]

Sensacional, como de costume.

[@marlonkkkk5kk]

Boa balta!! Muito bom o conteúdo, se possível gostaria de ver um conteúdo relacionado a persistência de domínios ricos, ainda há muitas lacunas no meu conhecimento relacionado a isso!

[@baltaio]

Opa, temos nos cursos!

[@joaopedrocorreia5874]

grande Fã

[@flaviodossantos9172]

Muito top

[@baltaio]

🚀

[@adriancampos2523]

Excelente

[@baltaio]

Muito obrigado

[@nao-enrola]

Selo #NaoEnrola! Obrigado pela aula top e gratis

[@baltaio]

[@baltaio]

Aliás, gostei do seu nome!!! #NãoEnrola

[@KakarooDev]

Valeu mestre #balta!

[@baltaio]

🚀

[@alevinciius]

Obrigado

[@baltaio]

[@ewa435]

Boa explicação. Queria saber quando e melhor utilizar begin trasaction do dbcontext ou unit Work?

[@baltaio]

Neste caso tanto faz... mas pode ter cenários onde você precisa transacionar entre DbContexts...

[@fpbbarros]

Obrigado pela aula... Vc poderia criar algo parecido sem usando o dapper no lugar do EF??

[@baltaio]

Vou tentar!!

[@ieieldoria]

Excelente, muito bem explicado. Fiz um curso seu, grátis, de Api, excelente tb. Tenho uma dúvida, se com muitos 'repositories' não ficaria muito extenso o ConfigureServices do startup? É isso mesmo ou existe um padrão diferente adotado para muitas dependências? De toda forma, novamente valeu pelo conteúdo.

[@baltaio]

Você pode segmentar isto em módulos, cada módulo com seu repositório e resolvendo suas dependências. Não precisam necessariamente ficar todos no Startup.

[@joaovictorcoutinho389]

Olá Balta tenho acompanhado seus vídeos e tenho gostado muito. Você explica os conceitos com exemplos simples e facilita muito o entendimento. Eu fiquei com uma dúvida, eu estou desenvolvendo um projeto com a abordagem DDD, com múltiplos domínios e portanto múltiplas camadas de infra e dbcontexts, mas apenas uma camada de API. Nesse caso aonde entraria o UnitOfWork? Cada contexto teria que ter sua própria UnitOfWork ou seria melhor criar uma camada de infra geral que importaria todos os dbContexts e faria o commit em todos? Obrigado pelos excelentes conteúdos compartilhados.

[@baltaio]

Você poderia ter apenas um UnitOfWork que faria o trabalho de unificar tudo que foi modificado nos contextos e persistir eles no banco.

[@karolinabento3103]

Boa tarde. Obrigada por compartilhar o conteúdo. Uma dúvida: Eu só uso então o padrão UnitOfWork se realmente eu tiver um método de inserção no controlador que tenha que inserir dois objetos juntos no banco (não podem ser inseridos separados)? É porque nesse caso, como você disse, normalmente o customer poderia ser salvo sozinho sim. Então para casos normais, que normalmente podemos salvar registros sozinhos no banco, ainda assim é legal utilizar o UnitOfWork? Qual o benefício nesse caso?

[@vinixdl]

Eu deveria adicionar todos os meus repositórios para a injeção de dependência? Somente os que eu mais utilizo? Se eu tiver 60 delas, o que faço?

[@baltaio]

Se você precisa consumir os repositórios, se precisa mockar eles para testes... ai não tem jeito, tem que adicionar. Talvez isto ajude: docs.microsoft.com/pt-br/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-6.0#register-groups-of-services-with-extension-methods

[@joaovictorferreira8380]

Excelente didática! Mas fiquei com um dúvida, poderia ser implementado o IDisposable? Onde ele ficaria no unit of work? Como ficaria o fluxo da aplicação?

[@adriancamposteixeira5483]

Balta, fala qualquer dia sobre as classes com diversas dependencias ou com diversos "imports"... como pode ser simplificado ou melhorado e tal.

[@baltaio]

Ótimo tema! Obrigado pelo feedback, vou tentar

[@luizpaulooliveira113]

É incrível sua facilidade em explicar!!! Só fica uma duvida quanto a esse rollback sem implementação: usou ele sem nada porque está usando um database em memória ou iria funcionar da mesma forma é um postgresql, mysql.. etc ?

[@baltaio]

Nem precisava do Rollback na verdade... Não tem nada pq n tá transacionando no banco!

[@87mtech50]

balta.io não foi preciso implementar o rollback pq implicitamente o entity faz uso do garbage para limpar da memória essas “solicitações” pendentes de persistência, certo? Se estivesse implementando essa persistência com ado.net, por exemplo, deveria ter alguma implementação no método de rollback, certo?

[@IcaroFelix2023]

Não poderia usar o controle de transação no unit of work e usar os Commit e Rollback deles ?

[@baltaio]

Acho que usamos exatamente desta forma, não?

[@kevinallen4872]

Balta, o que você acha da utilização de middlewares do asp.net core (ou até dos decorators do MediatR) para realizar o Unit of Work?

[@baltaio]

Nunca usei neste formato... mas pode ser interessante também... comitar automaticamente se deu tudo certo

[@guibestes]

Legal Balta! e se estivéssemos trabalhando com com shards, se cada cliente e seus pedidos ficassem em um shard diferente, claro, só pra efeito didático, de teria um exemplo sobre isso?

[@baltaio]

Depende... como está fazendo a comunicação entre contextos? Se for via eventos, não muda nada...

[@nao-enrola]

cara ta querendo um tutorial pra resolver o problema do trampo rs. Assim fica facil ser “senior”. Pesquisa home

[@alane7199]

Show de bola Balta! Didático e objetivo. Parabéns pelo vídeo! Qual tema do vs code você utiliza para estas cores de fonte?

[@baltaio]

Aqui estão as configs que uso => balta.io/blog/visual-studio-code-instalacao-customizacao

[@jonatanfelipe9315]

e a camada service é necessaria balta ?

[@GustavoHenrique-bm1co]

Tenho uma dúvida, estou implementando Generic Repository com os métodos básicos do CRUD, porém quando preciso de um método especifico crio na repository referente a classe, porém fiquei com dúvida de como passar o DBCONTEXT na repository, desta forma: private readonly ContextoTeste _context; protected UsersRepository(ContextoTeste context) { _context = context; } porém ele me acusa este erro: Não há nenhum argumento fornecido que corresponde ao parâmetro formal necessário "context" de "Repository.Repository(ContextoTeste)" como eu posso resolvo isso, pode me ajudar ?

[@baltaio]

Não tem motivo implementar um repositório genérico sobre um ORM... ele já fornece isto...

[@allefdouglas9693]

E se, ao invés desse padrão, for utilizado o context.Database.BeginTransactionAsync(); e logo após inserir todos os dados, utilizar o context.Database.CommitTransaction(); que já é fornecido pelo EF?

[@jessesantos7679]

Não seria melhor só fazer uma transaction com o EF core?

[@baltaio]

Este cenário é para quando queremos transacionar entre repositórios.

[@jessesantos7679]

@@baltaio aaaah sim, certo

[@marc2377]

Achei essa implementação superior a repositórios genéricos (que é supérfluo de se implementar sobre o Entity Framework). No entanto, a separação entre a Unit Of Work e cada Repository também não me parece a forma ideal. Na implementação que uso atualmente, os repositórios são propriedades da UoW. Então, além dos métodos Commit() e Rollback(), haveriam também as propriedades Customers e Orders. No caso, em 21:50, você só recebe a UoW no constructor, e também registra apenas o UoW na seção de dependency injections. Para acessar as collections, escreve: uow.Customers e uow.Orders. Essa implementação é bem demonstrada no seguinte vídeo (em inglês) do Mosh Hamedani: kzbin.info/www/bejne/qKW7oYymj8mCsK8.

[@baltaio]

Obrigado pelos pontos citados! Realmente parece supérfluo mas no meu caso por exemplo, eu tenho uma API e um App Web por exemplo, e ambos tem métodos de leitura parecidos. Neste caso por exemplo, os repositórios funcionam como um concentrador de informações, um ponto único de acesso. Se você só tem uma App consumindo os dados, concordo que não faz sentido... nem o UoW, afinal o EF já implementa os dois. Sobre os repos como propriedades no UoW, particularmente não uso pelos seguintes motivos: - Não sei como fica a gestão de memória com vários repositórios como propriedade. - Meu UoW normalmente cobre vários contextos, teriam muitos repositórios como propriedade - Por meu UoW cobrir vários contextos, ele fica em um contexto compartilhado, para adicionar outros repositórios como propriedades eu precisaria ter dependências destes outros contextos no meu contexto compartilhado, o que não seria viável. Mas de fato o padrão é ilustrado com repositórios dentro dele, inclusive pelo próprio Martin Fowler...

[@marc2377]

@@baltaio Opa, valeu pela resposta. O meu caso é parecido, tenho um Web App e uma Web API e implementei uma camada de serviços que serve ambos. Essa camada é o meu ponto único de acesso. Na minha primeira tentativa de implementação, fiz um repositório genérico mas logo percebi que fazia mais sentido usar o EF Core diretamente, o que fiz. A seguir, por motivos de separação de código de datastore e desacoplamento de ORM, até porque estarei consultando mais de um banco de dados, busquei implementar um repositório não-genérico (tal como o apresentado no vídeo) e essa me parece ser a solução correta no momento. Vi seu outro vídeo discutindo sobre repositórios genéricos e concordo com o que disse lá. Legal ver que sua estratégia é uma decisão consciente (mas não fico surpreso). Apenas posso afirmar que o primeiro ponto não é um motivo de preocupação, entidades vão sendo mapeadas e dados carregados na memória apenas conforme se vai utilizando cada repositório e método. Os outros dois pontos são ponderações válidas e como sempre, tudo depende do caso. Um abraço!

[@michelplatini9212]

Balta, tem algum curso de microServices disponível ?

[@baltaio]

Microsserviços ou APIs? Se for APIs temos sim. Lembrando que subir 2 ou 3 APIs e fazer elas se comunicarem não é Microsserviços... é o básico de APIs... Microsserviços envolve infraestrutra, banco de dados, DevOps e diversas outras coisas avançadas.

[@michelplatini9212]

@@baltaio inicialmente pode ser o de APIs mesmo, consegue me passar o link para acesso? :-)

[@rodrigo-tj1gf]

eu nunca tinha pensado em criar a interface e a classe no msm arquivo kkkkk, porra ficaria mt mais bonito do q oq eu faço

[@baltaio]

🚀

[@joaopedrobraghinmoreira2083]

Balta traz conteudo sobre bff

[@baltaio]

Best Friends Forever? 💜 Brincadeira... vou colocar na lista!

[@pgnt]

Obrigado pelo vídeo, mas não vi vantagem (pelo contrário, adicionou complexidade) no OUW, pois só se trocou a linha de comando com o ônus de ter uma classe a mais no sistema.

[@baltaio]

Realmente, se não viu vantagem, melhor nem usar!

[@pgnt]

@@baltaio sabe se tem ou enxerga de médio a longo prazo alguma vantagem/utilidade do uow ou concorda comigo que o componente trocou 6 por meia dúzia?

[@pgnt]

@@baltaio "bela" resposta, poderia usar o comentário para esclarecer mas preferiu fazer graça (seria melhor ter ficado quieto).

[@baltaio]

@@pgnt não foi "graça" foi sincero. Se você não vê benefício em um padrão então não use ele no seu projeto, só vai adicionar complexidade desnecessária. É melhor do que usar só por usar.

[@pgnt]

@@baltaio Ok, obrigado pelo retorno e sinceridade, é que a resposta deu margem para que eu interpretasse de forma errada. Só para contribuir então com quem estiver acompanhando, "uow" pode ser usado para quando precisar dar "commit" em "save changes" invocada por vários métodos de objetos do repository. abs

[@AlbertoMonteiro]

O próprio DbContext já é um UoW, por que criar uma outra classe para encapsular a chamada do SaveChanges?

[@baltaio]

Se você usar SOMENTE o DbContext para tudo, realmente não faz sentido ter o UoW...

[@AlbertoMonteiro]

@@baltaio O que me deixou curioso foi você não chamar o método do context.Database.BeginTransaction, para poder dar o Rollback no catch

[@baltaio]

Conforme comentei no vídeo, não precisa, pois enquanto você não usa o SaveChanges ele não persiste nada no banco.

[@nao-enrola]

no projetinho de tcc q tem duas classes blz, escreve ate a query na mao. Mas vai dar uma orelhada dessa e usar dbctx sem gerar log p suporte, sem try catch etc

[@nao-enrola]

Eh exemplo didatico Alberto, mas vc já ensina C# avancado. N foi pra vc esse vodeo

[@fbsouza]

Essa bosta do ef não tem um "cascade. All()"?

[@baltaio]

O que está querendo fazer?

[@fbsouza]

@@baltaio achei estranho ter que ir no repositório de cliente e de pedido, sendo que com NH, eu poderia ter uma lista de pedidos no cliente, mapeado com cascade. All. Deletorphan. Fazendo um add, ele persistiria os pedidos. No ef não há esse comportamento?

[@baltaio]

No EF também!

[@HeitorGiacomini]

detesto quando usa vs code é uma porcaria pra debugar e entender o codigo

[@baltaio]

👀

[@gustavodossantos6397]

22:25 para os Baianos e Nordestinos kkk

[@baltaio]

Para todos!

[@AnaHelena]

Excelente vídeo, balta! Só acho que você poderia falar menos "tá" e "né" no final de cada frase, prejudica um pouco o conteúdo. De resto, parabéns pelo trabalho! Assino o seu portal e acho o seu conteúdo excelente

[@baltaio]

Pois é, tenho muita dificuldade com os vícios de linguagem :(

[@aristotelescoutinho]

Você diz pra gente não fazer(ter duas classes por arquivo) mas faz. Não dá pra entender. hehehe

[@nao-enrola]

Da sim. Vc entendeu o q n eh pra fzr. Agora eh so n fzr. Isso eh dificil demais pra vc? Qto mimimi

[@baltaio]

Obrigado hahahahah

[@aristotelescoutinho]

Ué mas se o cara dizendo pra não fazer e tá fazendo. Só não faz e pronto. Não é nada pessoal.

[@nao-enrola]

Eh um exemplo didatico, cara.Rapido e pratico. Eh um prototipo. No seu github vc faz bonitinho do jeito q ele ensinou.

[@nao-enrola]

Aristóteles Coutinho me parece pessoal. tu deu curtir no video? Inscreveu no canal? cade seu comentario de “valeu Balta, bom conteudo! Nos proximos videos tenta n dizer uma coisa e fazer outra pra ilustrar melhor”. Isso eh uma crítica util. Seu comentario parece de quem veio procurar cabelo em ovo