Salve, beleza? Continuamos essa saga aqui no Domain Dreaming Design. Na última aula, nós testamos os últimos repositórios criados, que foi o de Customer e o de Evento. O de Customer deu tudo certo, mas o Evento, na hora de... Na verdade, nem é de persistir, na hora dele entender o mapeamento, quando a gente foi passar o Evento para ele, aconteceu aquele erro lá do getItems aqui. Ele tentou pegar uma collection, que foi justamente a da sessão, não é falado aqui, mas foi a sessão do evento. E a gente está trabalhando com o tipo set do próprio JavaScript. Mas ele tentou pegar um getItems aqui, porque o microRM trabalha com essas coleções, criando um formato dele em cima do set. Inclusive, será que dá para a gente poder ver esse tipo aqui? Isso é bom para que vocês entendam os desafios que você pode ter dependendo da sua linguagem de programação. Vamos pegar o microRMCore aqui. Será que a gente tem alguma coisa de collection? Acho que o nome é array-collection. quero pegar... Pode ser essa... Essa classe, na verdade, aqui, ela tem uma abstração. Na verdade, acho que é o collection que estende desse array collection. Mas esse array collection que, na verdade, está lidando com os itens fazendo um new set. Então, instancia esse cara, ele faz ali um new set, então eu instancio esse cara ele faz ali um um new set passando pra items, mas ele tem outras informações se essa coleção foi mexida, né, com o W ali, se foi suja e tem outros métodos também, tem um getItems aqui tem um getItems não, tá aqui em cima então se eu quiser pegar no formato de array e tudo mais, ele quer lidar com essas coleções dessa forma. E como a gente criou lá no nosso evento? Nós usamos o próprio set, como eu falei no início da aula e falei no final da outra aula. Então, a gente tem que fazer a paz e o igual, esse conflito aqui. Mas aí vem uma dica, na verdade, um conselho em relação a altas linguagens de programação. No caso aqui do MicroRM, ele criou uma coleção dele, usando algo ali do próprio JavaScript, mas quando você vai para linguagens como Java, como C Sharp, normalmente os caras que trabalham com Data Mapper, eles já vão usar o próprio tipo de collection da própria linguagem. Então, você não precisa fazer nada a princípio. No caso do Hibernate e do Entity Framework, funciona dessa forma. Agora, em outras linguagens, a gente tem que fazer essas verificações. No caso lá do Java, a gente poderia usar o tipo List ou ArrayList. O setup, de fato, eu não lembro. Mas aqui no caso do JavaScript, então, tem esse desafio. E aí é um problema, porque eu quero continuar trabalhando com algo que eu defino para não ficar dependendo de tecnologia, mas eu tenho que deixar essa collection no formato que o microRM trabalha também. Então, nós vamos, primeiramente, criar aqui uma abstração para poder apaziguar. E essa abstração vai ficar aqui no domínio. Então, My Collection. Porque nós... Quando a gente trabalha com uma abstração, então vou depender dela, ao invés de ficar dependendo diretamente do framework. Então eu quero ter um My Collection, que eu posso ter aqui qualquer coisa... Aqui é o objeto que eu quero trabalhar, vamos supor que eu queira uma coleção de eventSession, então passaria um eventSession para cá. E eu tenho métodos para poder brincar com esses dados, para poder capturá-los. Aqui no caso de capturar, estou colocando um tipo mais genérico do JavaScript, que não é o Array, que é o Interable. Me devolve qualquer coisa que é Interable, que que não é um array, que é um iterable. Me devolve qualquer coisa que é iterable, que todo iterable que você tem na sua linguagem de programação, que permite que você lide ali com for, coloque isso no while. No caso do JavaScript, todo mundo que é iterable tem que ter um símbolo .iterator lá com uma definição qualquer. Você pode definir a sua própria forma de interação. Java tem, PHP tem, todos têm. Então, nesse caso aqui, eu quero definir um getItems que fica fácil para poder capturar os itens, para poder adicionar um ou vários por extensa anotação aqui do spread operator para remover também. Um find, porque isso é importante ali, que eu tenho uma coleção e quero buscar algum por algum critério. Então, eu passo um predicado aqui, uma cláusula, que quando eu conseguir encontrar, eu devolvo aquele T, aquela instância, ou undefined, se eu não conseguir encontrar, um forEach para poder lidar ali diretamente com eles, um removeAll, se eu quiser remover todo mundo, e um count para saber quantos que tem. E, obviamente, essa collection em si, por si só, ela já é o interval também, então se eu jogar ela no for, ela já vai funcionar. Mas eu não consigo pegar esse iCollection e definir, mudar como que o microRM trabalha. definir, mudar como que o microRM trabalha. Poderia se ter até no RM, tipo, qual padrão de collection que você quer trabalhar. Tá, aí você passa ali, não tem. Então, eu estou definindo dessa forma, e aí agora eu vou usar um artifício aqui, que eu vou copiar uma classe... Inclusive, até tem algumas coisas para poder remover aqui, que são esses pontos. Eu acho que esse aqui, a expressão TypeScript não precisa. É que eu vou importar do microRM, e aí eu preciso daquela parte ali do TypeScript, sim. Beleza. Eu importei aqui em cima esse collection do próprio microRM, que é o collection que está sendo usado lá para as coleções dos relacionamentos. Então, olha o que eu vou fazer. Eu não posso desvirtuar o modo de coleção de trabalhar, mas eu quero fazer uma mudança na própria collection do microRM para inserir esse padrão aqui e a gente consiga trabalhar ao mesmo tempo aqui nesse relacionamento com o nosso padrão e não quebrando o do microRM também. Então nós vamos trabalhar com design pattern proxy. O design pattern proxy, inclusive eu já tenho o tipo proxy dentro do próprio JavaScript, às vezes em alguma linguagem a gente tem que fazer implementação vamos supor que eu tenha lá um objeto xpto que tem um devido método então quando eu gero aqui o meu proxy eu passo esse objeto para cá e aí eu posso ter um método chamando o próprio método original então aquela ideia de proxy de server antes de bater no server alvo vai bater no nosso proxy então a ideia é justamente essa aqui fica o código para vocês poderem dar uma olhadinha. Eu tenho dois métodos. Um para poder criar esse proxy aqui, passando uma referência qualquer, ou passando a instância diretamente da própria collection do type.orm. Por que eu tenho esses dois métodos? E esse aqui serviria para outras libs também. Aqui é quando eu quero criar essa coleção que vai ter esses métodos nossos e também com o padrão do próprio microRM de forma vazia, quando eu estou iniciando ali no construtor. E esse outro aqui serve para quando o microRM de forma vazia, quando eu estou iniciando ali no construtor. E esse outro aqui serve para quando o microRM carregar o relacionamento e for inserir lá, eu vou criar, eu vou pegar a collection que ele passar e vou criar um proxy em cima dela. Então, aqui eu crio o proxy vazio, que já tem toda a implementação, que olha o que está acontecendo aqui. Eu estou criando um novo collection dele, coloco esse initialized igual a false para falar que ele não está inicializado, que isso aqui é importante, porque senão depois eu não consigo adicionar os relacionamentos ali na coleção para ele poder salvar, então eu falo que ele não está inicializado, porque senão ele já cria aqui para mim inicializado. Ele precisa da referência da própria entidade. Então isso aqui é a própria entidade. E eu crio o proxy em cima desse collection. Ou eu crio o proxy em cima desse collection já pronto. Então tem um método createProxy que vai definir o proxy. E a gente tem alguns métodos aqui que são iguais, a própria coleção do microRM, então não preciso trabalhar, mas o que a gente precisa trabalhar é no find, no forEach e no count. Então, nós temos aqui a lógica para que a gente possa adicionar esse comportamento e ir nesse proxy para que ele saiba, opa, estou criando o proxy, se eu eu estiver chamando find, vai fazer isso aqui, não vai bater lá no original. Se eu estiver fazendo for it, vai bater aqui, não vai bater no original. O count é a mesma coisa. Então, agora, no evento, vamos usar aqui para... O evento, a gente vai ter que fazer uma pequena mudança aqui em sections. O evento a gente vai ter que fazer uma pequena mudança aqui em sections. Aqui nós vamos colocar como uma variável, com uma notação privada, ela não precisa ser necessariamente privada, mas aqui ela vai ser do tipo agora, que é o nosso iCollection, que vai lidar com o eventSession. Beleza. Então, aqui, a gente usa aquela factory lá para poder criar o nosso proxy. My collection factory, create, passando aqui a referência da própria, ele precisa, o collection lá do type, com o type urm na cabeça, do micro rm, ele precisa da própria referência. Isso aqui é para poder gerar, a coleção vai gerar por trás dos panos, a collection do micro rm, mas com a nossa implementação. Então, a gente consegue manipular ela tranquilamente. Aí, nós vamos chegar aqui embaixo, nós vamos criar um set e um getter. Como eu estou criando aqui de forma privada a gente está criando aqui de forma privada, inclusive pode até deixar isso aqui como um private. Nós vamos gerar aqui um get session Nós vamos gerar aqui um getSession e um setSession. Aqui, o que a gente vai receber? Eu não quero importar nada. O microRM, apesar de ele estar usando o construtor para hidratar as informações, para o relacionamento, ele acaba acessando a variável diretamente ali. Eu não quero importar nada aqui, mas eu recebo a collection dele. Então, eu poderia criar aqui um tipo... Eu poderia generalizar, porque depois eu posso mudar a lib, eu posso fazer assim, export type any collection que vai lidar com qualquer tipo que seja um objeto, é igual a collection t. Esse collection aqui é do próprio type url. Então eu poderia colocar um ou aqui, se eu tivesse várias libs de data map que eu estivesse trabalhando, aí esse nCollection é qualquer coisa que seja uma coleção ali que satisfaça as nossas necessidades. Então, ou nCollection de session. Ele até já colocou o que eu quero aqui. Então, eu quero fazer no thisSession criando com aquele createFrom aqui. Agora, ele vai mostrar um errinho em relação ao nCollection, que eu não importei ele e aqui ele vai falar que eu estou retornando no iCollection e tem aqui um conflito de tipo por causa do collection ele está falando, peraí, o seu collection o seu collection não tem esse lazy aqui loadItems que é lá do collection porque quando eu col não tem esse lazy aqui, load items, que é lá do collection, porque quando eu coloco esse carinha aqui, que ele está ligado ao microRM, ele vai falar que o getter não está compatível, porque ele conseguiu identificar outras propriedades. Então, a gente força aqui a conversão dele. Então, para todo relacionamento, a gente vai fazer isso aqui e também falando isso aqui devolve para a gente um iCollectionSession. Então vamos pegar isso aqui e passar lá para o Session no caso do Spot. Então aqui embaixo antes de fechar, importamos aqui o YCollection, aqui aonde está o event session, event spot e aonde está o session aqui vai ser spot importa se o collection my collection factory e agora a variável daqui de cima tem que ser vou colocar ela privada para não deixar ela acessível e confundir se a gente pode usar ou não. E aqui a gente pode fazer o... Está aqui. E aqui Spot. O que eu fiz de errado aqui? Aqui é Spot. Ah, aqui é Session. Aqui é Spot, na verdade. Pronto. Tem algum lugar que eu ainda... Fiz alguma coisa de errado? Ah, em relação aqui ao tipo, né? Eye Collection. Não temos mais nenhum erro aqui. Show de bola. Sumiu-se os erros. Aí, agora a gente tem uma questão aqui em relação aos spots. Se a gente passaria os spots ou não. Aqui agora a gente já chegou numa maturidade para poder avaliar isso. Não vale a pena a gente passar tudo isso aqui no construtor, até mesmo para não deixar mais complexo a criação de uma sessão ou a criação do próprio evento. Então, eu vou abstrair isso aqui. Eu vou retirar... Se eu quiser adicionar a sessão Spot, a gente tem uma operação para poder fazer isso. Não significa que eu tenho que criar tudo de uma vez, até mesmo porque o próprio ORM não vai fazer isso. Não significa que eu tenho que criar tudo de uma vez, até mesmo porque o próprio ORM não vai fazer isso. Normalmente os ORMs de outras linguagens também, ele não adiciona de uma vez ali, ele cria o objeto e depois faz com o setter. Então a gente vê aqui que para poder manter esse domínio rico, a gente tem que fazer certas adaptações. Então é o preço que a gente paga. Não existe uma situação perfeita, porque a gente tem que fazer certas adaptações. Então, é o preço que a gente paga. Não existe uma situação perfeita porque a gente tem que conciliar também a nossa modelagem com a tecnologia que nós queremos usar ali como persistência. Show de bola! Na próxima aula, a gente testa aqui para poder consolidar essa modelagem aqui com os nossos relacionamentos. Então, pessoal, é isso aí. E até a próxima!