OPINIÃO: POR QUE REPOSITORY COM ENTITY NÃO FAZ SENTIDO | ENTENDA

🚫🔄 Por que o Repository Pattern no Entity Framework .NET Não Faz Sentido? 🚫🔄
💭 No meu novo vídeo, vou te contar por que eu acredito que usar o Repository Pattern com o Entity Framework no .NET pode não ser a melhor escolha. Discutiremos questões como mockings, testabilidade e o impacto nos desempenhos devido a vários "includes". Também exploraremos por que, em alguns casos, o princípio DRY (Don't Repeat Yourself) pode não ser tão relevante quanto você pensa. Vamos desafiar as convenções e repensar o desenvolvimento .NET. Não perca! 🔍🔍
#EntityFramework, #RepositoryPattern, #DesenvolvimentoDotNet, #Testabilidade, #Performance, #PrincípioDRY, #Mocking, #OpiniãoDev, #DotNet, #Programação
/ cristian-silva-vieira
/ cristianwilliamdev

[@anderdsouza]

Usei repository pattern a vida inteira. Agora estou em crise existencial. Vou te mandar o boleto da terapia

[@cristianwilliamdev]

Hahahahah essa foi boa demais

[@DiegoTeixeira-vg]

Excelente vídeo, sobre ORM, eu prefiro desenvolver as querrys na mão mesmo para otimizar bem a performance

[@yendisgomes2831]

Bem legal a opinião em cima desses cases, ajuda bastante a refletir. Sentia falta de um canal assim de .NET, mão na massa. parabéns ;)

[@cristianwilliamdev]

Que dahora! Ai sim cara! Fico feliz de ter curtido! Tmj mano!

[@Jh0natasHenrique]

Defendo isso a duas décadas. Ganhou um inscrito! Parabéns pelo trabalho!!

[@cristianwilliamdev]

shbsahusahusuha Boaaaa!

[@ricardorocha5118]

Tem um sênior no meu projeto, que implemmentou Unit of Work, Repository Pattern, Raio que for Pattern, tudo... Interface pra queries síncronas e assíncronas. Pra fazer uma mudança simples numa query, eu precisei alterar uns 10 arquivos, ou seja, uma bosta. Acho que a maturidade de projeto conta muito mais do que saber patterns/tecnologias e usar tudo no automático. Parabéns pelo conteúdo, caí de paraquedas aqui e curti muito!

[@cristianwilliamdev]

Simmm, já passei da fase de querer implementar tudo o que sei pra dizer que foi feito por um Sr, com o tempo a gente ganha maturidade! Te convido a assistir meu vídeo de automapper, maneiro demais também.
Já aproveita que caiu de paraquedas e se inscreve aí mano pra fortalecer!

[@N0151]

Concordo e assino embaixo.
Essa percepção do que é necessário acredito que vem com o tempo. Já fui a pessoa que em projeto pessoal colocava tudo, hj já penso um pouco mais.

[@cristianwilliamdev]

Boaaa!

[@SpacialCow]

Faz MUITO tempo que não mexo com C#, mas seguindo o video eu tenho algumas duvidas e considerações:
1. Como usar o repository pattern previne voce de usar o change tracking? O que previne no caso seria montar a query na mão, não? (Não ficou claro pra mim)
2. Uma vez que voce não tem algum lugar centralizado (que voce tem domínio) pra acessar os dados, como voce faz? Deixa fazer acesso ao contexto em qualquer lugar sem nenhum padrão? Essa minha pergunta seria mais direta a encapsulamento, não necessariamente a favor/contra o repository pattern.
3. Qual seria alternativa solida a isso, principalmente pra projetos grandes?
A muito tempo quando eu usava C#, eu notava o "uso" do repository pattern, porem, nos métodos que retornavam as entidades, estavam fazendo o uso dos métodos add/where/etc do próprio entity e não montando a query na mão, eu pessoalmente gostava por conta de >>ter um lugar especifico>> public Person getByAddress(String address) { }

[@cristianwilliamdev]

Salve mano! Aqui vai algumas ideias, que tentarei responder!
1 - Não é que previne de usar o Change Tracker, é que se a ideia é abstrair a ferramenta (como muitas vezes acontece), usar com o change tracker, iria quebrar seu codigo em uma possivel troca, a não ser que voce iria implementar isso. Em alguns casos, já vi repository pattern retornando DTO, neste caso, é necessário executar um SELECT para fazer o projection, onde o EF automaticamente iria ignorar o Change Tracker.
2 - Não mano, a gente manteria o dominio sim, as regras de negócios ficariam encapsuladas nas entidades mesmo.
3 - Não entendi essa mano! Sorry!
Sim, sobre o repository pattern a ideia inicial é manter a camada de acesso a dados separada, nesse caso teria apenas um lugar para procurar mesmo, mas a ideia do video não é dizer que não funciona, e sim que não acrescenta tanto valor quando usado com o Entity mano!
Sim mano, eu imagino que funcione mesmo, mas neste caso esta filtrando a pessoa por endereço, e no exemplo, eu quis dizer, onde voce precisa retornar pelo ID da pessoa, um endereço TAMBÉM,
Tmj, Obrigado pelos comentários! Vamooo!

[@FelipeSilva-lo5qz]

Grande Cristian.
Parabéns pelo conteúdo.
Sou novo na área e gosto muito do C#.
Tenho um sugestão de vídeo, poderia mostrar como você faria para validar dados e regras de negócio de uma entidade?

[@cristianwilliamdev]

Claro meu brother, vou deixar aqui na lista, mas de antemão, eu prefiro a ideia não deixar que uma entidade tenha os sets publicos, e que não possam ser criadas de forma invalida, para isso, eu gosto de usar factories, e um bom construtor.

[@gabrielporto3936]

Fala Cristian, te sigo faz algum tempo e acho muito bom os seus vídeos e os seus conteúdos, parabéns! Esse assunto sempre gera muita discussão e eu mesmo sou um cara que gosta muito de usar o repository pattern mas sempre uso o select para retornar somente as propriedades necessárias e assim ganhar em performance... você poderia fazer um vídeo mostrando a criação de testes sem usar o repository pattern?

[@cristianwilliamdev]

Opaaa, obrigado pela moral mano! Anotei aqui, essa ideia vai ser basicamente fazer o seed em memoria do contexto do EF.

[@aspnetpro]

Boa, Cristian!
Tenho o mesmo pensamento em relação ao uso do pattern Repository com o EF pois todo esse probelam relatada já vivenciei na prática.
Conteúdo pertinente que poucos falam!
Parabéns!

[@cristianwilliamdev]

Obrigado mesmo man! Então, isso a gente só ve na experiencia mesmo, quando alguem apresenta um novo pattern e não temos exp, dificilmente é exposto os pontos negativos!
Curti por ter gostado mano! Trabalhando mais para isso mesmo!

[@aspnetpro]

@@cristianwilliamdev Tamo junto, conteúdo simples, muito real e prático tem que ser disseminado!

[@alanfondareis]

Excelente vídeo mano, ganhou mais um escrito! Eu acho que isso depende muito do tamanho do projeto, e regras de negócio. Ultimamente tenho utizado só o dapper pra tudo. Eu achei que o desempenho das aplicações sempre ficam muito mais rápido. Vou continuar acompanhando suas coisas por aqui, valeu mano!

[@cristianwilliamdev]

Sim mano, como os adv, a gente sempre "depende" muito do cenário... Mas é isso, sobre o Dapper, eu recentemente tenho usado os métodos FromSqlQuery, FromSqlRaw do EF, tem me atendido bastante... Já testou?

[@gregorifelicio6030]

Engraçado que um dia perguntei para um amigo o motivo dele usar repository patern no projeto que ele estava criando, e a resposta dele foi "Mas não é assim que se usa entity?". Fiquei pensanro rs

[@cristianwilliamdev]

Para esse ai, o Repository Pattern já faz parte do template do webapi sahusahusa!
Tmj mano! Tu é foda!

[@rogersrodriguesmustafa6513]

@@cristianwilliamdev Ser desenvolvedor de software não é so escrever código é ser analista também. 😄

[@rogersrodriguesmustafa6513]

Pessoal experiente avisa toma cuidado com design patters, para não viciar e enfiar eles em tudo, tem que analizar se realmente é nescessário, princípio kiss funciona muito bem.

[@cristianwilliamdev]

Vlwww demais! Galera as vezes usa pra alimenta o ego sahuahsushau

[@rafaelscheffer1262]

são ótimos pontos e fazem sentido, consumindo diretamente o contexto do entity framework a gente não precisa nem da implementação do unit of work mas não gosto muito de ter as queries espalhadas nos serviços e é por isso que eu também não gosto muito de usar predicate, agora vou pegar algum projeto pessoal que tenho e refatorar pra remover o uso do repository e ver como que fica heheh

[@cristianwilliamdev]

Entendo o seu ponto! Volta pra dizer o que achou da ideia, não esquece de analisar as queries geradas pelo Entity!

[@Patinhow100]

Ótimo vídeo, irmão!
Assunto polêmico e necessário. Eu sigo por essa mesma linha de raciocínio, se for necessário, eu prefiro "me repetir" do que criar funções/queries porcas pra seguir um padrão falho.
Esse papo de repository eu praticamente nunca uso. Vejo gente que leva isso como uma religião, usa em TODO SANTO PROJETO e eu considero que esse alguém falhou em reconhecer as necessidades do que está construindo e simplesmente faz o que viu outra pessoa falando que é certo.
Caí de paraquedas e gostei mesmo do conteúdo. O vídeo todo parecia que eu tava ouvindo um amigo meu conversar. Parabéns pelo trabalho!

[@cristianwilliamdev]

Aiiii sim mano! Exatamente, já vi uma galera que acha que o repository pattern faz parte do template do dotnet new webapi ushashuahusa!
Fico feliz de ter curtido o jeito meu de conversar mano! Não quero trazer o technes aqui, quero falar mais como se fosse um papo normal mesmo!

[@marcoscarvalho9956]

Gostei e vou repensar para esse caso pois uso muito EF. Valeu.

[@cristianwilliamdev]

Vou trazer mais sobre EF.

[@rogersrodriguesmustafa6513]

Analise cada caso. É comendado usar os dois, aonde você está fazendo muito acesso a determinados dados faz as querys na mão.

[@danielfernando9725]

Boa! poderia realizar uns projetos de .NET, igual o que rolou com o angular. Bom vídeo

[@cristianwilliamdev]

Ta saindo do forno para essa semana, sera um projeto explicando de forma bem simples como criar uma API e consumir com o Angular, bem iniciante mesmo!

[@alabi9]

Já precisei trocar o entity por cause de performance

[@Ilovecode]

Muito boa suas reflexões

[@cristianwilliamdev]

Vlw demais mano!

[@carlospdiase]

Como estou mais familiarizado com tecnologias do mundo Java, estou tirando minhas conclusões do nome do padrão mencionado.
Eu desconfio de que o nome 'repository' venha de um padrão tático do Domain Driven Design.
Embora seja erroneamente utilizado na camada de persistência, o padrão 'repository' pertence na verdade
à camada de negócio e tem como objetivo abstrair a forma de persistir os objetos, podendo ela
ser um webservice, banco de dados com sql, jdbc, Hibernate(Java), Entity (dot net), etc...
O modelo hexagonal com portas e adaptadores também deixa essa separação mais clara.
Essa abstração faz muito sentido em projetos de média e alta complexidade.

[@cristianwilliamdev]

Concordo contigo mano! Sim, em projetos de media e alta faz sentido, mas ainda sim, eu pensaria quando utilizar, na grande maioria dos casos não faz sentido na minha opinião

[@dellmachado85]

Mais uma aula Top. Você consegue trazer um vídeo falando de Nhibernate? Fazer um crud com ele.

[@cristianwilliamdev]

Mano, pra mandar a real, eu não tenho planos, já que meu background é .net. Talvez um dia, mas não prometo não.

[@AnndreJunior]

Msm começando no mundo do .net até que tua opinião tem bastante lógica
Como eu comecei no typescript e nodejs eu usava o repository pattern pq o prisma não tem essa função de criar um banco em memória igual o ef, aí eu usava o repositório pra mockar um banco em memória pra testes unitário do caso de uso
Pelo visto esse é um trabalho que eu não vou precisar ter no .net

[@cristianwilliamdev]

.Net é vida sauhsuhahuas na verdade a grande maioria dos ORMS de Node, são baseados no Entity, ou seja, o Entity é melhor suhahusahusa Minha opinião totalmente parcial pro lado da Microsoft suhauhshusa

[@AnndreJunior]

@@cristianwilliamdev só não falo o contrário pq tô começando a estudar c# e .net e tô amando kkkkkkkkkkk

[@inocencio.cardoso]

No meu caso, eu não coloco as propriedades que representam as tabelas no banco dedados, no DataContext. Eu faço mapeamento com Fluent, crio um único repositório genérico, e na hora de fazer as consultas, na controller ou num service, eu faço assim:
Vários registros: _repository.Query(p=>p.Enderecos).Where(filtrar aqui);
Um registro: await _repository.Query(p=>p.Enderecos).FirstOrDefaultAsync();
Onde ainda consigo incluir outros dados da pessoa de foma simplificada, assim como os Endereços.
Se precisar consultar outra tabela, basta substituir a classe Pessoa para a classe desejada.

[@cristianwilliamdev]

Eu entendo seu ponto, mas ainda sim na minha opinião como mostrado no video, eu não vejo valor neste tipo de abordagem... Eu já trabalhei dessa forma, ainda sim é uma abtração sem muito valor.

[@raphael-carneiro]

Fala Cristian! Você trouxe um bom ponto. Me diga uma coisa, seria uma boa abordagem ter no repository um método dinâmico que receba nos parâmetros além do filtro os includes desejados e um bool para definir se utiliza ou não o AsNoTracking? Parabéns pelo conteúdo!

[@cristianwilliamdev]

Então mano, na real, isso parece mais que voce esta tentando adaptar o Repository Pattern com Entity para suass necessidades, é como eu disse no video, é interessante avaliar os casos, se realmente se faz necessário usar essas ferramentas! Pensa ai mano!

[@AlexCarlos]

Cara, até entendo seu ponto e na maioria dos casos realmente não faz sentido. Porém em alguns projetos mais robustos, utilizamos a camada de repository pra adicionar cache. Então lá a gente define se vai buscar do cache ou direto do banco de dados. E aí sim faz sentido, pois podemos usar implementação de cachê usando Kafka ou qualquer outro. Sem contar toda a lógica pra manter os dados em cache sempre quentes e coisas mais complexas que na camada de api e aplicação não faria sentido ser manipulado.
Mas excelente vídeo, parabéns

[@cristianwilliamdev]

Opa dependendo da ideia do projeto, usar cache faz sentido também mano, neste caso, é uma implementação interessante... No caso, quando tive que implementar cache uma vez, como estava trabalhando com Mediatr, eu implementei um middleware em alguns casos de uso para isso, mas para Repository faz total sentido também.
Obrigado por adicionar sua exp mano! Tmj Alex!

[@proibidobs7130]

Include porque? O Entity não tem aquela propriedade de navegação? (dúvida mesmo)

[@cristianwilliamdev]

Salve mano! Quando se esta usando o select, e acessa a propriedade de navegação, o angular automaticamente faz um join, agora quando se tem um repository pattern, e não está executando um select, tipo, voce retorna o modelo de dominio mesmo, nesses casos, caso queira um join, sem fazer o select, é necessário usar o Include, e as vezes até o ThenInclude!

[@lumaandreza6972]

👏👏👏👏

[@cristianwilliamdev]

TE AMO MEU AMORRR!

[@TecnoPlayCanal]

Eu entendi o problema mas não a solução :x
Pra qual camada o Get iria? e como eu faria pra não repetir todo o comando do EF em vários lugares que precisam dele?

[@cristianwilliamdev]

O get eu manteria diretamente na camada de Application, se voce trabalha com aplicações em camadas, e costuma ter uma camada de dados para o EF, teria que criar uma interface para conseguir usar o EF nessa camada de application...
Para não refletir o comando do EF, é só criar uma função para isso, ou não? huashusausa Não sei se entendi bem a pergunta mano, tmj!

[@user-tm5bw8kz1p]

Bom video, mano. Tipo, é parecido com spring data jpa. Só que o spring data jpa abstrai muito mais coisa e dá fazer query dentro do repository. Ai mano, qual o nome dessa font ai?

[@cristianwilliamdev]

No entity também mano, o context já é nosso repo, e da pra usar o linq do entity junto, fica bem maneiro.
Mano a fonte chama: Operator Mono with ligatures, mas os itálicos da fonte são definidos pelo tema, night owl que mudei umas cores pra eu gostar hahaha

[@carlosoliveiratube]

Bom dia Cristian, espero que esteja tudo em paz...tenho algumas duvidas em relação a este video. Como ficaria uma arquitetura bem estruturada sem utilizar o repository?

[@cristianwilliamdev]

Cara, depende da necessidade / complexidade do projeto, eu não digo que não usaria o repository, mas só usaria em casos específicos, acredito que usar o Entity na camada de Application mesmo, faria mais sentido na maioria dos apps hoje. Mas como disse, isso vai mais da complexidade do projeto.

[@paulosoares1912]

Se o dev está aplicando Repository Pattern apenas como uma interface de manipulação genérica de banco de dados é porque não entendeu Repository Pattern.
Uma das características desse padrão é espeficifar a manipulação (ENCAPSULAMENTO!!!). Um Repository de Identity deve expor métodos relacionado a Identity: SignIn, BlockUser, ChangePassword, etc.
Uso como exemplo os modificadores de acesso do C#. Eu poderia criar os setters das minhas entidades como publico, poderia ignorar "private", "protected", "init". Nada me obriga a utilizar classes seladas (sealed) e internas (internal). Vai funcionar da mesma maneira, certo? Mas se tiver brecha pro Dev fazer cagada, acredite, ele vai fazer!
Podemos também falar de Clean Code onde legibilidade e manutenabilidade é o foco. Aí é assunto longo e mais polêmico ainda haha.
Sobre mudar o framework, dificilmente vai acontecer mesmo. Mas o que pode acontecer é você precisar aumentar a performance de leitura, talvez optando em utilizar um micro ORM (Dapper, por exemplo). A equipe do EF vem trabalhando muito forte na melhoria da performance de leitura e isso é inegável, pode ser que isso se resolva por completo nas próximas versões, mas ainda não chegou lá.
Se teu sistema é um CRUD simples, tranquilo, acesse diretamente o EF que vai ser muito mais fácil.
No final, o que vale é entender que Patterns tem casos de uso específicos e que não se mata uma formiga com uma bazuca (mata, mas não precisa).

[@cristianwilliamdev]

Mano! Exatamente isso, o que faz sentido no repo, é quando voce precisa de uma parada mais especifica que metodos cruds, costumo chamar de Specific Repository Pattern!
Obrigado pelos comentários, tu é foda!

[@programedegraca]

E se precisar trocar de ORM ? Precisar mudar do EF pro Dapper, por exemplo, o repository não ajuda ? ??

[@cristianwilliamdev]

Nesse caso eu criaria um repo com somente os metodos do dapper, nesse caso faz sentido sim, é isso que comento no final do video... Uhhh Obrigado pelo comentário!

[@erickjhonata5193]

kkkkk q doidera isso faz total sentido, ainda mais pra um crud basicao, acho q o repository so vai ser mais aproveitado quando estivermos tratando de situacoes mais especificas

[@cristianwilliamdev]

Gosto de repo para trabalhar com situacões bem especificas, onde precisamos por exemplo fazer uma query especifica para uma operação especifica... Mas para operações de CRUD... Bobeira, vira uma abstração da abstração

[@kleberksms]

Vou dizer que sou um cara que concorda por motivos diferentes e discordo por motivos diferentes
motivo de não usar o repository
- eu sempre começo qualquer projeto com o mínimo de camadas possíveis, então da para iniciar sem o repositório
motivo de usar o repository
- quanto não existe mais um mapeamento direto entre a camada de domínio e o acesso aos dados, e estes por sua vez se tornam como o nome diz, apenas um repositório de persistência destes dados.

[@cristianwilliamdev]

Boaaa mano, exatamente, sempre começo também com o minimo de camadas, inclusive, pensando no projeto como um todo, as vezes tenho apenas uma camada (ex: Microservice enxuto - esse enxuto ficou redundante hahaha)
Mas sim, dependende do caso, a ideia do video foi mostrar o que é perdido com a implementação casual de repositiory onde muitos devs, quando se fala de acesso a dados, já vai logo criando o repo como se fosse uma regra.