Balta, está sendo muito bom esses seus vídeos curtos, ajuda até mesmo a reforçar nossos conhecimentos, quando no dia-a-dia a gente acaba acabamos esquecendo esses fundamentos, Parabéns 👏
Eu sinceramente mesmo já tendo o datacontext e mesmo a aplicação sendo basicamente Crud eu prefiro usar repository sim,acho uma boa pratica ,demora um pouco mais porém pode ser que num futuro a aplicação tenha que crescer aí fica mais fácil
Uso repositórios genéricos e ajuda muito no desenvolvimento, até porque nossa aplicação não acessa somente um banco de dados (context), mas diversos, dependendo da requisição, então, repositórios genéricos fazem muito sentido para a nossa solução.
@@baltaio Numa aplicacao comercial com muitas regras de negócio (alem do CRUD, contas receber/pagar, pedidos, vendas, compras etc) seria justificado a abordagem de reposirorio para o crud e "repositorio generico específico" (como muitos DEV chamam) para as regras de negocio?
balta, tudo bem que o framework EF faz tudo que o repositório genérico faz, mas e o acoplamento que isso geraria no domínio sem uma interface para corrigir esse problema?
Você pode mockar o IDbContext... mas mockar um repositório seria mais prático neste aspecto... se quer especificidade, repositórios são o caminho, se quer rapidez, o DbContext é a solução.
Balta, no caso de uma API(que serve um front end) e que consome outra API(essa não pode ser acessada pelo front), acha válido encapsular as chamadas numa espécie de repositório ? (Podia ter uma prática dessa ein hahaha)
Olá Balta, sou estagiário a 7 meses, e Ví esse video sobre anti-pattern, e achei válido comentar... Quando começei num projeto na minha empresa, utilizamos muito Dapper no Começo, e aprendi com um Dev a questão do Generic Repository... Gosto muito do dapper e queria que vc analisasse o que fazíamos... Utilizávamos a seguinte estrutura de Repository: AlunoRepository : IAlunoRepository IAlunoRepository : IRepository Pelo que descrevi, utilizávamos um IRepository no qual continha todo o CRUD básico, e implemetações expecíficas colocávamos em IAlunoRepository... O que vc acha dessa maneira de usar esse Pattern???
@@baltaio Tocando nesse assunto que vc falou no video, hoje, já uso o Dapper e o EFCore juntos... Acho bem massa ter os 2 juntos em um projeto... E mais uma dúvida: - Minha evolução nisso é que já consigo criar uma Aplicaçao usando múltiplos contextos, tipo: Auth, Blog, User Settings e por ai vai... Acha isso uma maneira certa de usar o EFCORE??? E valeu ai pela força, o primeiro vídeo que vi sobre EFCore foi um dos seus... Pois bem, muito obrigado pelo conteudo... Show!!
O que eu penso é que... se não vejo vantagem em um padrão, só vejo código desnecessário e blá blá blá... então está errado... talvez não precisava do padrão... pode ser seu caso! 💜
Valeu Balta, seu conteúdo é muito bom e agrega sempre. Obrigada!
Show de bola o vídeo, é sempre muito legal esta troca de conhecimento e opiniões. Valeu Balta !!!
Balta, está sendo muito bom esses seus vídeos curtos, ajuda até mesmo a reforçar nossos conhecimentos, quando no dia-a-dia a gente acaba acabamos esquecendo esses fundamentos, Parabéns 👏
Eu sinceramente mesmo já tendo o datacontext e mesmo a aplicação sendo basicamente Crud eu prefiro usar repository sim,acho uma boa pratica ,demora um pouco mais porém pode ser que num futuro a aplicação tenha que crescer aí fica mais fácil
Uso repositórios genéricos e ajuda muito no desenvolvimento, até porque nossa aplicação não acessa somente um banco de dados (context), mas diversos, dependendo da requisição, então, repositórios genéricos fazem muito sentido para a nossa solução.
Concordo, mas neste caso apenas o DbContext não bastaria? Precisa mesmo do repositório?
@@baltaio Numa aplicacao comercial com muitas regras de negócio (alem do CRUD, contas receber/pagar, pedidos, vendas, compras etc) seria justificado a abordagem de reposirorio para o crud e "repositorio generico específico" (como muitos DEV chamam) para as regras de negocio?
Muito top o conteúdo!
balta, tudo bem que o framework EF faz tudo que o repositório genérico faz, mas e o acoplamento que isso geraria no domínio sem uma interface para corrigir esse problema?
Você pode mockar o IDbContext... mas mockar um repositório seria mais prático neste aspecto... se quer especificidade, repositórios são o caminho, se quer rapidez, o DbContext é a solução.
Showww muito top , veio de encontro com o que estou com estudando ultimamente , top abraços
Valeu Humberto!
Balta, no caso de uma API(que serve um front end) e que consome outra API(essa não pode ser acessada pelo front), acha válido encapsular as chamadas numa espécie de repositório ? (Podia ter uma prática dessa ein hahaha)
Sim... muitas empresas que fornecem API, fornecem uma SDK junto que faz exatamente isto
Olá Balta, sou estagiário a 7 meses, e Ví esse video sobre anti-pattern, e achei válido comentar... Quando começei num projeto na minha empresa, utilizamos muito Dapper no Começo, e aprendi com um Dev a questão do Generic Repository... Gosto muito do dapper e queria que vc analisasse o que fazíamos...
Utilizávamos a seguinte estrutura de Repository:
AlunoRepository : IAlunoRepository
IAlunoRepository : IRepository
Pelo que descrevi, utilizávamos um IRepository no qual continha todo o CRUD básico, e implemetações expecíficas colocávamos em IAlunoRepository...
O que vc acha dessa maneira de usar esse Pattern???
Usando Dapper nem tanto, agora usando EF, podia usar o DataContext direto...
Por outro lado, usar Dapper pra CRUD por qual motivo? Não rolaria um EF?
@@baltaio Hm, acho que uns dos motivos é q o Sistema já nasceria com uma complexidade muito grande de entidades...
@@baltaio Tocando nesse assunto que vc falou no video, hoje, já uso o Dapper e o EFCore juntos... Acho bem massa ter os 2 juntos em um projeto... E mais uma dúvida:
- Minha evolução nisso é que já consigo criar uma Aplicaçao usando múltiplos contextos, tipo: Auth, Blog, User Settings e por ai vai... Acha isso uma maneira certa de usar o EFCORE???
E valeu ai pela força, o primeiro vídeo que vi sobre EFCore foi um dos seus... Pois bem, muito obrigado pelo conteudo... Show!!
Massa!!!
talvez esteja generalizando, mas um repository pattern em cima do entity framework que já implementa esses padrões é código desnecessario
Depende! Se você precisa testar itens que dependem do DbContext, como faz para mocka-los sem o uso do repository?
@@baltaio faço o uso do banco em memoria para teste.
@@baltaio para queries que podem se repetir, utilizo extension method.
@@baltaio como falei, acho desnecessario, mas nao julgo quem faça.
@Balta, depois dá uma olhadinha no card que aparece no final do vídeo, está escrito "7x MVP". Você é merecidamente "8x" ;)
Obrigado
Já vi projetos implementarem o repository chamar uma classe dao que eu não consegui ver vantagem nenhuma disso
O que eu penso é que... se não vejo vantagem em um padrão, só vejo código desnecessário e blá blá blá... então está errado... talvez não precisava do padrão... pode ser seu caso! 💜
mete na pratica ....
Teoria também é importante!
@@baltaio sim é verdade mas gosto tanto de ver a magia acontecer.