OPINIÃO: POR QUE REPOSITORY COM ENTITY NÃO FAZ SENTIDO | ENTENDA
āļāļąāļ
- āđāļāļĒāđāļāļĢāđāđāļĄāļ·āđāļ 25 āļŠ.āļ. 2024
- ðŦð 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
Usei repository pattern a vida inteira. Agora estou em crise existencial. Vou te mandar o boleto da terapia
Hahahahah essa foi boa demais
Excelente vÃdeo, sobre ORM, eu prefiro desenvolver as querrys na mÃĢo mesmo para otimizar bem a performance
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 ;)
Que dahora! Ai sim cara! Fico feliz de ter curtido! Tmj mano!
Defendo isso a duas dÃĐcadas. Ganhou um inscrito! ParabÃĐns pelo trabalho!!
shbsahusahusuha Boaaaa!
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!
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!
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.
Boaaa!
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) { }
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!
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?
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.
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?
Opaaa, obrigado pela moral mano! Anotei aqui, essa ideia vai ser basicamente fazer o seed em memoria do contexto do EF.
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!
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!
@@cristianwilliamdev Tamo junto, conteÚdo simples, muito real e prÃĄtico tem que ser disseminado!
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!
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?
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
Para esse ai, o Repository Pattern jÃĄ faz parte do template do webapi sahusahusa!
Tmj mano! Tu ÃĐ foda!
@@cristianwilliamdev Ser desenvolvedor de software nÃĢo ÃĐ so escrever cÃģdigo ÃĐ ser analista tambÃĐm. ð
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.
Vlwww demais! Galera as vezes usa pra alimenta o ego sahuahsushau
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
Entendo o seu ponto! Volta pra dizer o que achou da ideia, nÃĢo esquece de analisar as queries geradas pelo Entity!
Ã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!
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!
Gostei e vou repensar para esse caso pois uso muito EF. Valeu.
Vou trazer mais sobre EF.
Analise cada caso. à comendado usar os dois, aonde vocÊ estÃĄ fazendo muito acesso a determinados dados faz as querys na mÃĢo.
Boa! poderia realizar uns projetos de .NET, igual o que rolou com o angular. Bom vÃdeo
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!
JÃĄ precisei trocar o entity por cause de performance
Muito boa suas reflexÃĩes
Vlw demais mano!
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.
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
Mais uma aula Top. VocÊ consegue trazer um vÃdeo falando de Nhibernate? Fazer um crud com ele.
Mano, pra mandar a real, eu nÃĢo tenho planos, jÃĄ que meu background ÃĐ .net. Talvez um dia, mas nÃĢo prometo nÃĢo.
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
.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
@@cristianwilliamdev sÃģ nÃĢo falo o contrÃĄrio pq tÃī começando a estudar c# e .net e tÃī amando kkkkkkkkkkk
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.
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.
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!
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!
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
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!
Include porque? O Entity nÃĢo tem aquela propriedade de navegaçÃĢo? (dÚvida mesmo)
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!
ðððð
TE AMO MEU AMORRR!
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?
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!
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?
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
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?
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.
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).
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!
E se precisar trocar de ORM ? Precisar mudar do EF pro Dapper, por exemplo, o repository nÃĢo ajuda ? ??
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!
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
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
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.
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.