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

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

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!

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

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 ;)

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

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.

Quando eu vi o título do vídeo eu pensei "como assim cara, tá maluco?". No primeiro tópico que trouxe já me convenceu que faz sentido hahaha

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?

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!

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?

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) { }

Tenho a mesma opinião, unica coisa que fico pensando é que se estivermos usando uma abordagem DDD, o repositório é um objeto de domínio e nesse caso mesmo que seja por cima de um ORM poderoso acredito que ainda faz sentido.

Muito boa suas reflexões

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!

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

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

👏👏👏👏

Ó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!

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

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

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!

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

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

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?

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.

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?

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?

eu acho uma burrice fazer o padrao repository em cima do ef kkkkk

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

Já precisei trocar o entity por cause de performance

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

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

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.

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.

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).

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

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.