.NET BR 🇧🇷

14 July 2025 21:08

Fala galera o que vcs tem utilizado como alternativa ao declarativeSql.Core e Dapper para .Net 9.0?

.NET BR 🇧🇷

14 July 2025 16:51

Tiraram boas dúvidas do Jr fake aqui

.NET BR 🇧🇷

14 July 2025 16:38

Muitos questionamentos acumulados ao longo do tempo kkkk

.NET BR 🇧🇷

14 July 2025 16:34

É que você tem várias perguntas num texto só...rsrsrs

.NET BR 🇧🇷

14 July 2025 16:33

Nao tem muito contexto não, só dúvidas aleatórias mesmo kkk

.NET BR 🇧🇷

14 July 2025 16:29

Quando eu uso repository, eu gosto de saber que eu estou livre a camada de acesso

.NET BR 🇧🇷

14 July 2025 16:28

Acabei esbarrando nele, mas acho que vou precisar estudar um pouco mais sobre

.NET BR 🇧🇷

14 July 2025 16:26

Tenho usado unit of work pra resolver

.NET BR 🇧🇷

14 July 2025 16:20

OneTimePassword é sim.

MagicLink seria a mesma coisa, só que o link já loga direto.

Mas o academia tem outros controles para você não gerar o link para outro, etc etc.

O token só é válido naquela janela do browser...
tem uma série de detalhes a respeito disso.

.NET BR 🇧🇷

14 July 2025 16:19

É similar ao que tem no academia.dev?

.NET BR 🇧🇷

14 July 2025 16:18

Vou pesquisar a respeito. Muito obrigado.

.NET BR 🇧🇷

14 July 2025 15:51

1) Eu me guio pelo princípio de que expressões lambda que viram SQL estão no escopo do acesso a dados.

E portanto, elas nunca poderiam sujar minha camada de core, services, negócio, chame como quiser.

.NET BR 🇧🇷

14 July 2025 15:22

Bom dia, preciso da visão dos companheiros de senioridade maior aqui do grupo.

Não sei nem por onde começar kkk

Ultimamente tenho visto bastante uma discussão sobre o uso do repository ou não (ao menos para ORMs mais "completas" tipo o EntityFramework ou Eloquent), considerando apenas o uso direto do acesso à dados na camada de serviço, de certo modo faz sentido e traz agilidade ao desenvolvimento por não ter o repository, mas e a respeito de consultas complexas? Faria o mesmo direto na camada de serviço? Assim teria que repetir a consulta toda vez que fosse utilizar ela, sinto que o código ficaria mais complexo de ler, mais difícil de testar por um ganho pouco significativo. A partir disso faria sentido o uso do repository para essas questões, mas aí cheguei em outro problema. Na clean archtechture (até onde entendi), a implementação do acesso a dados fica na camada de infraestrutura e seriam expostas apenas as abstrações à camada de serviço, no caso para tratar transações eu faria um método para o begin transaction, commit e rollback em cada repository? Um base repository? E quanto a relacionamentos? Teria que criar variação de método buscando os relacionamentos e tudo mais? Buscaria todos os relacionamentos de uma vez?

Ficou meio textão, mas espero que minha dúvida tenha ficado clara

São mais dúvidas que vinheram do nada mesmo

.NET BR 🇧🇷

14 July 2025 05:24

Puts, já fiquei curioso!

Kkkk

.NET BR 🇧🇷

14 July 2025 05:17

Eu pretendo mexer aprender essa parte o dotnet com foco em web mesmo, acho válido aprender primeiro. A questão dos jogos é mais por um hobby mesmo, pois acho muito interessante.

.NET BR 🇧🇷

14 July 2025 17:16

🔵 [Online|13:15|Análise + Segurança de Código: MegaLinter|Gratuito]
Fala galera! Daqui a pouco - a partir das 13:15 - horário de Brasília - estreia mais um vídeo gratuito - com chat ao vivo para dúvidas - no Canal .NET. Confira neste conteúdo como a solução open source MegaLinter pode ser útil em análises de qualidade e segurança em código, através de sua execução em pipelines de automação e ao suporte que a mesma oferece a dezenas de outras ferramentas gratuitas. Tudo isso em um exemplo executado a partir de um pipeline do Azure DevOps, facilmente adaptável para scanning de projetos em stacks como C#/.NET, Java, Node.js, Python, PHP, Go, Flutter, Ruby...: https://www.youtube.com/watch?v=57CAxYP0bLQ

.NET BR 🇧🇷

14 July 2025 16:50

É isso, valeu aí guys

.NET BR 🇧🇷

14 July 2025 16:35

Se você quiser mudar o método de acesso aos dados de EF para Dapper daqui a seis meses, teria que mudar coisas na camada de aplicação (ou outro número de camadas que façam referência à camada de acesso a dados) e não só na camada de acesso aos dados, por exemplo.

.NET BR 🇧🇷

14 July 2025 16:33

Ao meu ver a camada de aplicação (ou qualquer outra camada) não deveria saber nem se preocupar com qual método de persistência ou acesso a dados a camada de acesso a dados utiliza; se está num banco de dados MSSQL e o acesso é feito via Dapper ou Entity Framework, se está num banco de dados NoSQL ou se é uma chamada a um serviço externo, os que consomem a camada de acesso aos dados deveriam só receber uma interface dizendo "eu recebo isso e te retorno isso"; permitir que a camada de aplicação faça queries via EF significa vazar detalhes de implementação de acesso a dados (uso de EF invés de, por exemplo, Dapper) para o cliente (aplicação).

.NET BR 🇧🇷

14 July 2025 16:29

Mesmo que eu esteja usando um ORM

.NET BR 🇧🇷

14 July 2025 16:29

Eu não sei o contexto do seu problema...Mas o uow me da uma sensação de estar sempre ligado à um ORM...

.NET BR 🇧🇷

14 July 2025 16:27

Eu sempre achei ruim esse pattern rsrs

.NET BR 🇧🇷

14 July 2025 16:22

Entendi, mas está ótimo já ter um termo para iniciar as buscas. Obrigado novamente.

.NET BR 🇧🇷

14 July 2025 16:19

Mas realmente, há situações em que pode ser interessante expor eles

.NET BR 🇧🇷

14 July 2025 16:18

Sim sim, falo isso porque teoricamente vai contra a ideia que eu tenho de o dado sair concreto do repository

.NET BR 🇧🇷

14 July 2025 16:17

Pensei em gerar um e-mail aleatório em cima do domínio principal balbalba123@dominio.com

.NET BR 🇧🇷

14 July 2025 15:49

sua pergunta é super interessante, bora falar sobre.

.NET BR 🇧🇷

14 July 2025 13:19

Muito maneiro, é algo avançado, mas imagino que seja de muita importância.

.NET BR 🇧🇷

14 July 2025 05:20

ainda estou trabalhando na capa

.NET BR 🇧🇷

14 July 2025 05:17

Esse PDF eu gerei pelo Microsoft Loop.

Ainda está em Beta, mas se não conhece vale a pena testar!