Obsessão por tipos primitivos

[@plablooo]

Cara, até momento não tinha encontrado em nenhum outro canal um conteúdo tão rico e técnico como os que tem no EximiaCo. Parabéns!

[@jeffersonferreira43]

Programação Avançada...que todo mundo deveria saber.

[@edudolino]

Um vídeo de menos de 20 minutos que vale mais que muitos livros. E eu achava que já sabia alguma coisa de programação.

[@EusouFeioEdai]

Utilizar struct faz total sentido. Ótimo conteúdo

[@karamazovsc]

Esse tipo de conteúdo agrega muito, obrigado!

[@DiasDeDev]

Usar exceções como controle de fluxo é um baita assunto eu eu gostaria muito de te ouvir falar sobre isso. Abraços e parabéns pelo trabalho. Sou seu fã!

[@rhmuller]

Excelente vídeo, parabéns. Uma didática muito boa, e mesmo com um exemplo "simples" como um CPF, conseguiu deixar claro o problema e a solução.

[@wagnerbreggi2943]

Muito bom e muito obrigado por todas as AULAS que vc está disponibilizando nesse canal. Muito obrigado mesmo !

[@ruandias6257]

Explodiu minha mente! Parabéns pelo excelente conteúdo! 🎉🎉🎉

[@ciroformenton]

Conhecimento que vale OURO!!!!

[@ddrsdiego]

Eu tinha aprendido sobre obsessão por tipos primitivos num post do Vladimir Khorikov aonde por consequência entendi sobre Value Objects. A diferença da implementação é que ele cria um método estático para criar o objeto encapsulamento numa classe Result que diz se foi possível ou não criar a classe. Excelente vídeo.

[@daltoncorbetta7206]

Sou programador iniciante no C# e tenho que concordar, raramente vi conteúdo técnico com tanta riqueza de detalhes e tão bem explicado como os da EximiaCo. Parabéns e sucesso a vocês! Vocês mais que merecem.

[@danielchagas9502]

Muito obrigado por compartilhar conhecimento. Muito precioso para quem é Jr. e quer se aprimorar! Vlw!

[@adsonsantos1930]

Que aula maravilhosa! Conteudo super rico, simples mas muito util

[@MrRomviana]

Excelente exposição. Eu aprendi a programar nos anos 80, quando muitos computadores eram limitados a 64k, 128k de RAM, no máximo; quando os dados tinham que ser gravados em diskettes. Tínhamos que economizar memória em tudo... até no nome da variável;no tamanho do código fonte, pra poupar memória. Muitas vezes usávamos C ao invés de CONTADOR num laço FOR. A exemplo de CPF e CNPJ, são números, portanto, o ideal, no meu entendimento, é usar o tipo correto para o dado. No caso do CPF, é preciso uma variável numérica de 8 bytes pra gravar um CPF, mas se usar string, precisará de 11. Multiplique esses 3 bytes a mais trafegando pelo seu HD, seu banco de dados, pela sua rede, pela memória de servidores de banco, de aplicações, e client´s. O mesmo vale para aquele campo "S" ou "N", que, no MS-SQL por exemplo, pode ser representado por um campo tipo BIT ao invés de um CHAR(1), sendo que BIT é 8 vezes MENOR que CHAR(1). Em muitas tabelas pequenas, onde o identificador do registro não vai passar de 100, pode-se usar o campo Tynint. Esse identificador poderá ser replicado em muitas outras tabelas filhas ( FK ) e essas normatizações ajudam muito a reduzir o peso do banco e das aplicações. Eu me assusto quando vejo muitas APPS com 20, 30, até 40 MB em executáveis e agregados, sendo que a maioria delas poderia facilmente não ultrapassar os 10MB.

[@dcernach]

Excelente ponto!

[@kevinallen4872]

Que eloquência, meus amigos... que eloquência!

[@dcernach]

Isso de fato é ótimo... Costumo usar Records no .NET7, uma coisa que acaba deixando um pouco mais chato é a serialização, onde há de se implementar os devidos JSON/XML Serializers e Value Converters no caso de utilizar esses tipos em WebApi's e no Entity Framework... No meu caso, eu evito implementar os Implicit Operators, escolhendo geralmente um factory method, como por exemplo Cpf.From(value). Sou meio contra a lançar Exceptions de construtores, No fim, eu acredito que é um trabalho que vale muito a pena e sempre o faço... Existem até Code Generators em .NET7 para implementar automaticamente esses tipos...

[@AndreAbrantesBR]

Parabéns, ElemarJr! Vídeos de excelente qualidade! Está contribuindo muito com a comunidade. Já pensou em fazer uma "live" com Perguntas e Respostas? Acho que isso poderia contribuir ainda mais! Grande abraço!

[@EximiaCo]

Por agora, ainda nada planejado.

[@lsalomao07]

Conteúdo do canal está incrível! E com uma explicação simples.. Parabéns Elemar

[@devPauloPinheiro]

Agora você me puxou na memória uma obra que me marcou na juventude e início da carreira, o livro de Gane e Sarson, "Análise Estruturada de Sistemas", em que um dos entregáveis do analista era algo como um dicionário de dados. Interessante porque saía dos tipos primitivos e forçava a pensar em propriedades comuns. O ORM que trabalho atualmente é o Django (Python) e ele tem suporte a criação de tipos personalizados para uso no ORM, e vejo como um recurso importante para tirar esses detalhes do 'utils' :) e concentrar em um lugar mais apropriado. Abraço e parabéns pelos vídeos, que tem sido muito úteis até para mim, que não sou do mundo .net.

[@felipemelo437]

Ótimo conteúdo, com certeza um dos melhores canais BR sobre dot net. Obs : Vale um video sobre o mapemaneto em ORMs hein... Obrigado ...

[@rodcorporation]

Explicação perfeita Elemar!!!! boa perspectiva sobre a situação. Achei mto bacana.

[@perciodalpozzo]

Elemar sou teu fã :) Obrigado sempre pelos conteúdos

[@diegocantelli]

Vendo essas aulas percebo que não sei programar, mas aos poucos chego lá!

[@alessandrodesouza]

#tmj

[@vmamore]

Muito massa Elemar, obrigado, depois que começamos a criar tipos para as coisas é um caminho sem volta kkkk abraço

[@rafaelrosa3841]

o que eu vejo nisso é que utilizando o CPF como classe isso pode dificultar no mapeamento para um ORM, o que praticamente obriga a utilizar outra camada de classes que serão mapeadas e de classes que são de domínio, é um trade-off, além de no caso de utilizar um MVC faríamos 3 conversões de objeto, objeto mapeado -> entidade de dominio -> model, mais camadas mais complexidade e mais processamento também, muitas vezes não é uma decisão tão trivial.

[@AlbertoMonteiro]

Esses drops em vídeos são sensacionais!!

[@vagnermello]

É sempre um prazer assistir seus videos! Muuuuuuuuuito obrigado :)

[@carloswanderley8868]

Que abordagem incrível! Uma aula de conhecimento e boas práticas. Adotarei essa abordagem a partir de agora. Parabéns!!!

[@putzz67767]

Bela aula!

[@nacasadobeirinha1524]

Sempre com otimo conteudo, meus parabens! Eu acho que faz total sentido, sempre que faz sentido para não tornar "complexo" demais transformo atributos em campos. Outra coisa que tenho costume de fazer é quando classes tem algumas regras, crio algo relacionado a regras que é consumindo pela classe em si. Exemplo se CPF tivesse muitas regras, teria um CPFRegra ou validacao e as implementações estariam ai, sendo consumidas pela CPF via agregação, mas isso pensando em casos grandes e é claro em arquitetura. O que acha do uso de agregação pensando em casos maiores, onde temos uma classe Processo e ela contem regras, validacoes e outros itens, acharia valido adicionar outras classes com essas responsabilidades via agregacao. O implicit realmente nos codigos que ja visitei de empresas que trabalhei não havia o costume de ser utilizado o que acho um desperdicio, pois fazemos conversao implicita com primitivos direto. Mais uma vez parabéns pelo conteudo. Grande abraço!

[@CleberRobertoMovio]

só uma dúvida, no caso do nome, seria correto tratar como tipo também, levando em consideração a abordagem, seria um tipo porque o nome poderíamos ter a separação do nome como lastname, middlename e firstname, seria essa a ideia?

[@davidg12bh]

Excelente Aula.

[@rafaelsanjosify]

Excelente conteúdo, parabéns.

[@omaximilliam]

Muito bom, Elemar. Seu conteúdo é excelente. O seu mindset está agregando muito na minha carreira, obrigado!

[@gustavoferrazfontes6981]

Elemar, o ideal é que tenhamos as nossas regras e validações encapsuladas em nosso Domain model, como você exemplificou no vídeo, você deu uma expressividade maior para o que é o CPF, criando o tipo CPF. Imagine que há um Fail Fast ou qualquer validação previa dos dados de um payoload que um endpoint recebe. Entre esses dados, eu tenho o CPF onde eu já queria valida-lo. Gostaria de saber: Como você trataria essa questão de validação? Como você evitaria a duplicação de código e a descentralização de regras e validações do seu Domain Model? Excelente o vídeo. Parabéns.

[@rodolfonat]

Quando voce mandar enviar o request com o seu payload, o campo cpf vai vir como string (ou nulo, ou qlq coisa pq vc nao garante o que vem do client). Esse request vai bater no endpoint. O .net vai converter a string cpf do payload para o Tipo Cpf usando o operador implicit e nesse momento vai fazer a validação.

[@rodolfonat]

No caso, o Elemar tá falando que validação de CPF é tão básico que nao deveria ser considerada como regra de negócio.

[@HumbertoPereira1994]

Excelente video Elemar !!

[@viniciusbeloni3199]

Preciso fazer algumas perguntas. Criei minha classe de CNPJ e CPF e tive alguns problemas: 1. O Dapper não reconhece, precisa implementar um TypeHandler pra resolver e implementar um operador implicito para string 2. JSON não serializa como string, preciso entender como resolver sem fazer gambiarra 3. O Swagger não sabe mostrar os tipos CNPJ e CPF como string Teoricamente são problemas esperados, afinal, é uma struct e não uma string, mas é uma dor de cabeça a mais pra resolver. Pensei em só criar esses tipos para as camadas da API, pq assim eu garanto a entrada. De qualquer maneira, ficou muito legal.

[@ojuliomiguel]

Nossa, muito bom!

[@cjaferre]

Grande Elemar! No modelo proposto, a validação de Cpf ocorre ao construir o objeto. Num cenário onde vou ler grandes quantidades de "Employee" de um storage, onde previamente já validei o Cpf, o que recomenda para evitar ter que revalidar um Cpf desnecessariamente? Grande abraço!

[@rodolfonat]

é a função Parse que ele mostrou no vídeo. Parse: Converte sem validar. TryParse: Converte com validação.

[@cjaferre]

@@rodolfonat Parse chama TryParse e a validação ficaria no TryParse (mas não foi implementado), como citado em 11:10. Como não fazer a validação?

[@lucasoliveira1026]

Talvez você poderia tornar o construtor de CPF público e, nesse caso, utilizar o "new Cpf(repository.Employees.Cpf)"

[@BwolfDev]

Exelente video =D

[@abraaohonorio]

Mais um excelente vídeo, parabéns pelo incrível trabalho 0/

[@otechlead]

niiicoo

[@379Felipe]

Caramba, gostei bastante do conteúdo. Só alguns minutos de vídeo que acabei vendo umas coisas que nunca tinha visto antes. Dúvida, acha que vale a pena fazer esse tipo de implementação quando se trabalha com grande volume de dados? ou nesse caso seria melhor se manter nos tipos primitivos?

[@carloslima8858]

Muito Bom!

[@EduardoSpaki]

ótimo conteúdo. dúvida ingênua: como mapear isso para um ORM, ex EF? (obs: eu sei que temos que priorizar o design ao invés da ferramenta/orm)

[@Renanfa1]

Acredito que seja preciso fazer um mapeamento customizado. No mongo pelo menos é preciso, pois ele não entende a conversão implicita

[@fanturyP]

Muito bom, mais eu tenho uma duvida caso tenha uma classe Cliente com um tipo Endereco, onde contem varias propriedades como Logradouro, Numero, Bairro, Cidade, UF etc... todas essas informações estão dentro de uma unica tabela "Cliente" no banco de dados, a duvida é como o EF Core irar tratar isso ?

[@ricardovicentini]

Muito bom Elemar, pode se dizer que essa uma implementação de ValueObject do DDD? Com struct tiramos o objeto da heap e poupamos recursos, mas existe algum efeito colateral? Obrigado.

[@carlosl8832]

👍🏽

[@niss2011]

O struct tem um construtor sem parâmetros obrigatório e sem possibilidade de sobreescrever, ou seja, seria possível criar um CPF vazio. Faz sentido?

[@otechlead]

Muito interessante este tipo de conteúdo, tenho uma dúvida: O uso de structs no lugar de classes é uma boa prática para quando representamos objetos de dados em um ORM (Entity, Dapper, etc)?

[@ddrsdiego]

Se eu puder dar uma contribuição como trabalho, geralmente eu uso struct com dapper para trazer um objeto POCO e depois "hidratar" minhas entidades. Não sei se já viu assim mas o que acha?

[@otechlead]

​@@ddrsdiego Eu acho interessante, a minha dúvida maior é se isso pode gerar benefício de desempenho.

[@otechlead]

Eu estou com um app pra refatorar que está consumindo muita memoria e estou avaliando melhorias neste ponto

[@carloswanderley8868]

Olá Elemar. Uma dúvida a respeito: na implementação de uma classe (Employee) que representa uma tabela de dados de um banco de dados, para uso com frameworks como o Entity Framework, o definição da propriedade Cpf como do tipo Cpf - e não string - traz algum problema com o uso de Fluent API e até mesmo Migrations?

[@alessandrodesouza]

Elemar, sem querer abusar da sua bondade, mas poderia criar um vídeo falando sobre Exceptions .. fiquei curioso e pra variar devo estar fazendo errado :(

[@angelorfontana]

Show

[@rafaelferreira4011]

A maior dúvida e como salvar isso em banco. O jeito correto usando ORM ou Dapper

[@tjlimaster]

Essa e minha dúvida também

[@MSMaldi]

A struct de CPF minha fica parecida com a sua, mas value que vc usa string uso int, e guardo apenas o CPF sem o digito, ou seja, para 123.456.789-09 após a validação guardo apenas como inteiro 123.456.789, o que acha?

[@EximiaCo]

Lindo! :)

[@ncvjr]

E como você faz com cpfs que começam com 0?

[@MrRomviana]

@@ncvjr não tem nenhum problema... armazena no banco sem os zeros da esquerda. Estes, apenas são exibidos na app usando formatadores de números.

[@rafapioli75]

Uma dúvida, tem como seguir essa mesma abordagem com uso da conversão implícita para um campo cujo retorno tem o tipo primitivo diferente de string? Exemplo, Idade do tipo int. Nesse caso não poderia usar o ToString() para retornar o valor automaticamente.

[@lucasoliveira1026]

@@rafapioli75 No exemplo do CPF, você pode querer converter de string com máscara (999.999.999-99) para string sem máscara (99999999999); ou de double para string com máscara. No caso da idade, qual seria a razão para conversão?

[@BrunoSilva-sq6xr]

Devo criar também objetos para nome e Id?

[@eduardotovao]

Caraca.. refatorando minha classe de utils em 3..2..1 kkkkkkkkkkkk

[@roqlee]

Top!

[@alessandrodesouza]

Nunca mais uso tipos primitivos nas minhas entidades .... :( .. e parece ser ótimo.. kkkkk

[@alessandrodesouza]

@Soluções Simples vc tem razão.. mas não foi em sentindo literal.. :)

[@IsmaelGasparinBill]

Excelente!!!