C# | Como EVITAR a obsessão por TIPOS PRIMITIVOS? (Ainda acontece muito...)
Вставка
- Опубліковано 5 лют 2025
- No vídeo de hoje vamos ver como a obsessão por tipos primitivos pode levar nosso código a falência. Será mesmo que devemos usar tipos primitivos? Vamos ver tudo isso em detalhes.
🔻🔻 Outras informações importantes 🔻🔻
💻 LinkedIn para Devs: linkedin.giare...
👉 Se inscreva no canal: bit.ly/giarett...
Quando falamos em C#, estamos falando em um oceano de boas práticas e código.
Dentre uma delas, podemos ver com certa frequência a obsessão por tipos primitivos. Será que realmente é correto usar esse tipo de abordagem?
Se você tem esse duvida, esse vídeo é para você!
Pode ter certeza que esse vídeo irá te ajudar. Fica comigo aqui no vídeo, e qualquer duvida ou sugestão é só deixar nos comentários 😊
Grande abraço,
Henrique Giaretta
Software Developer
Simples e muito eficaz, estou implementando em meu projeto!
Tmj demais. Grande abraço.
Tão simples, mas tão efetivo! Mais um inscrito com certeza
Tmj demais. Obrigado. Grande abraço
Suas aulas são sensacionais, estão sendo essenciais para meu aprendizado!
Muito bom ler isso. Tmj demais. Sucesso. Abraço.
Muito top a dica
Valeeeeu, tmj.
Dica top.
Valeeeu, Tmj!
Obrigado pelo conteúdo! +1 SUB
Valeeeu. Tmj. Abraço.
Meus parabens meu amigo.
É de coração que lhe digo isso.
Conteúdo de qualidade e muito aproveitador, muito bem explicado e com uma temática incrível.
Por isso que estou escolhendo o C# .
Valeeeu. Fico feliz em ler isso. Tmj demais.
Parabéns Giaretta! Gostei muito do contéudo! Essas dicas estão agregando muito nos meus estudos!!
Valeeeu. Obrigado pelas palavras. Tmj. Abraço.
Muito bom! Tem que sempre estar atendo!
Valeeeu, Igor. Temos que estar sempre pensando no melhor do código. Grande abraço.
Cara, essas dicas são ótimas sacadas. Obrigado por este conteúdo, show!
Valeeeu Gabriel, que bom que tu curtiu. Grande abraço, tmj.
Muito bom camarada! Parabéns!
Muito obrigado pela palavras. Grande abraço.
O título do teu vídeo me assustou, quando vi as classes entendi o assunto. Bom encontrar um defensor dessa prática. Tive oportunidade de aplicar a técnica em endereço do cliente, de 5 props virou uma com validação em único local. Parabéns pelo conteúdo.
Faala Elton, não se assuste rsrs. Eu gosto dessa prática, pois muitas vezes usar tipos primitivos não vai nos ajudar. Fico feliz que tenha curtido. Grande abraço.
Achei maravilhoso. Mas fiquei com algumas dúvidas que eu não soube resolver sozinho... Se puder me ajudar agradeço imensamente.
Digamos que minha entitie que usa esse e-mail vai ser mapeada pelo Entity FrameworkCore... Como vou identificar ela para o EF? Como ele vai converter para o tipo de coluna no BD?
Sei da existência do [Column (Type = "TipoDesejado")], mas a dúvida é, como ele vai converter o tipo Email para Varchar2? Agradeço desde já!
Mais uma vez, excelente conteúdo, mostrando os detalhes e o brilhantimo da POO.
Opaa, fala aí Gustavo. Obrigado pelas palavras. A forma mais fácil para você fazer isso é usar o ComplexType, mas ficaria um pouco extenso de explicar por aqui. Em resumo, você pode usar o ComplexType e passar o tipo do seu tipo complexo.
Eu vou fazer um conteúdo sobre isso para ficar mais fácil de entender. Pode ser?
Grande abraço e obrigado pela ideia. Tmj.
Opa. Pode ser sim, seria ótimo! Valeu! Abraço!
Ótimo vídeo. Sempre com temas bem relevantes 👏
Faala Pedro, obrigado pelas palavras. Tmj.
Mais um ótimo vídeo.
Você sabe se comunicar bem e isso faz total diferença na hora de consumir um conteúdo na internet... Logo logo estará com milhares de inscritos. Sucesso!
Valeeu Filipe. Fico feliz em saber que esteja curtindo o conteúdo. Obrigado pelas palavras. Tmj.
Tenho a mesma opinião. Sabe muito bem expressar. Parabéns
Muito legal essas dicas. Mas fiquei numa dúvida: Isso vai dar certo na hora de fazer migrations com o banco de dados? Posso usar tipo complexo à vontade nas minhas models?
Faala Diogo. Obrigado pelas palavras. Pode usar sim, mas tu vai ter que configurar o mapeamento do EF de forma correta. Vou trazer um conteúdo sobre isso para te ajudar. Grande abraço.
Acontece que "string" não é um tipo de dado primitivo !!!
string txt = "";
Type type = txt.GetType();
bool b = type.IsPrimitive;
b resulta false ...
Aliás em nenhuma linguagem string é dado primitivo !!! string é um char[] ou byte[]
Mas ok....
deu para perceber com evitar dados genericos e evitar possiveis erros na passagem de parametros.
Obrigado pela observação. Grande abraço.
nunca gostei de criar tipos complexos, 1) vamos ter que criar uma instancia pra cada email e a performance? 2) como fica as validações com um fluent validator? teriamos 2 instancias pra cada email? uma dele mesmo e outra do validator? 3) como ficaria a situação com os DTOs? 4) como retorno os erros de validação para o usuário? 5) sempre aprendi a manter a lógica da aplicação em apenas um lugar, mas utilizando tipos complexos "espalhariamos" a lógica por aí 5) caso precisamos criar um Person na mão, teriamos que ficar passando new Email(" "), new TalCoisa() por parametro
OBS: não confunda eu não gostar de tipos mais complexos com não gostar do seu vídeo, eu defendo que o video exista, e que todos entendam a proposta e apliquem quando necessário
Faala Jeferson. Com certeza, são pontos válidos e que vão depender de projeto para projeto. Como tudo na programação, tem lados bons e ruins, e temos que optar qual ferramenta/funcionalidade seguir. Obrigado por compartilhar seu pensamento e obrigado por estar aqui conosco. Grande abraço.
Os Value Objects (Objetos de Valor) têm vantagens interessantes, como imutabilidade, clareza de nomes e encapsulamento. No entanto, pessoalmente, tenho algumas ressalvas em relação ao seu uso devido a preocupações com desempenho. Cada instância de um Value Object consome memória, o que pode ser problemático se houver a necessidade de criar muitas instâncias com grande volume de dados. Além disso, a questão da serialização e persistência também me preocupa. Tem que ter cuidado ao usar!
Faaala Leonardo. Tudo bem? Tu tens razão. O uso excessivo pode trazer algumas complexidades em termos de desempenho. Até o momento, eu nunca tive nenhum problema de desempenho por causa dos VOs. Já tive alguns gaps por outras questões, mas nunca pelos VOs. Tudo o que usamos em programação temos que ter o cuidado da dosagem, mas na minha opinião os VOs é um baita recurso que podemos usar a nível de aplicação/arquitetura. Tmj, grande abraço.
Pode clarificar melhor o objetivo disso que tu fez ai, me pareceu uma abstração inútil, não tá agregando nada fazer isso ai
Tu literalmente fez um wrapper pra uma string e botou um validator que retorna true ou false mas o valor de retorno da função nunca é usado.
Qual o intuito disso, vai dar throw no construtor?
Também isso ai adiciona complexidade desnecessária à serialização e mapeamento.
Ele encapsulou a lógica de validação de email, evitando repetição. Utilização de DRY com o pilar da POO (Encapsulamento). Sobre nunca ser usado, é porque era um exemplo. A ideia é usar pra validar o campo e aceitar ou não o valor inserido.
@@gustavovalente3228 mas e aí, é se falhar a validação, ia lançar exception em construtor?
Modelo tem que ser só modelo, não pode tirar do processo a autoridade de validar ou não
Opaaa, boa tarde. Cara, realmente a ideia é como foi comentado, mostrar uma ideia de Value Object, para usar ao decorrer da aplicação ao invés de criar props como string (o que pode prejudicar a escalabilidade com o tempo). A ideia não é mostrar como usar, pois existem n possibilidades, mas sim, mostrar que é viável ter VOs para nossos modelos.
Inutilidade é uma questão de opinião, e eu respeito a sua. Eu gosto e sigo muito o conceito de domain notifications, que até podemos usar a biblioteca Flunt para isso. E por isso acredito que o VO é muito válido.
O intuito do vídeo é mostrar como criar o VO. Sobre retornar true ou false, novamente, é somente um exemplo pois o intuito do vídeo não é mostrar sobre criar validações. Você pode criar a regra de validação da melhor forma que você entender.
Eu discordo da opinião que modelo deve ser só modelo. Modelo deve ter validações, e esse é um dos principais motivos de privarmos o set da propriedade também.
E também não concordo em lançar uma excessão dentro do construtor. O que pode ser feito é validar a informação e atribuir a informação a propriedade, caso contrário não atribui. Mas enfim, existe um oceano de possibilidades que podemos fazer. O intuito aqui era somente mostrar VO, que na minha opinião é uma forma elegante de validação.
Tmj, obrigado. Grande abraço.
Um adendo eu assisti o video anterior e no contexto deu pra entender melhor porém esse video aqui isoladamente não se explica bem por si só, não entenda mal, seus videos são bons e bem gravados, tem um bom audio, boa didática, esse um video aqui sozinho não ficou bem explicado o bastante. Eu discordo que modelos ricos sejam "objetivamente melhores", mas entendendo o contexto do video anterior eu com experiência de longa data consigo filtrar o que ficou errado nesse video, imaginar como seria da forma correta, e entender o que tu quis dizer. Mas alguém iniciante e ainda mais sem o contexto do video anterior provavelmente vai aprender coisa errada com a forma como ficou explicado aqui.
O que eu acho que tu quis dizer: Crie uma classe email que não armazena valor caso falhe a validação, e use isso nos modelos ao invés de string.
O que tu ensinou: Faça uma classe wrapper de string com uma função validadora que não valida nada.