Bom pessoal, no vídeo anterior a gente falou sobre o conceito principal quando nós estamos falando sobre Gateway. Agora, o que eu quero que vocês entendam aqui é que nós temos duas formas de acesso principal à utilização dessas Gateways, quando a gente está falando em objetos que encapsulam responsabilidades para falar com o mundo externo. Na realidade, você vai ver que navegando nos patterns, a gente acaba tendo mais formas. Mas as duas principais formas aqui, quando ele está falando sobre gateway, a forma número um é a gente falar que a gente tem um tipo de dado, um tipo de objeto que a gente chama de Row Data Gateway. O que isso significa? Que é uma instância para cada linha retornada para uma consulta. Então vamos imaginar que eu faço uma consulta no banco de dados, eu pego o retorno ali comigo e então o que acontece? Para cada retorno que eu tenha, para cada linha, no final do dia eu tenho um objeto. E, além disso, se eu quiser fazer persistência ou consulta de dados, eu também posso ter acesso a métodos como insert, update, delete, find, etc. Mas o grande ponto aqui é que no final do dia, toda vez que você recupera um dado, você vai perceber que a sua equivalência ao objeto é de uma linha por objeto. E é por isso que a gente chama esse camarada de Row Data Gateway. Legal? Então, esse aí é o nosso forma número um, vamos dizer assim, de a gente conseguir trabalhar. Por outro lado, nós temos uma outra forma aqui que é bem interessante. é o nossa forma número um vamos dizer assim ea gente conseguir trabalhar por outro lado nós temos uma outra forma aqui que é bem interessante tá que a gente chama de estrutura genérica de tabelas e linhas que limitam a natureza tabular de um banco um recorde 7 uma classe por tabela e isso a gente chama de table data gateway legal então o que acontece enquanto a role de irá gateway ele pega cada recurso por linha tá a table de irá gateway o que ele retorna pra você um recorde 7 e quando a gente fala que é um recorde 7 é um conjunto de registros tá então a idéia dele aqui é conseguir simular como se você tivesse a tabela inteira do banco de dados em memória dentro dos seus objetos então isso aí que é interessante e você vai perceber que você vai ter exatamente uma classe por objeto de tabela. Então, imagina assim, que eu estou trabalhando e do jeito que a gente está falando aqui, pessoal, a gente está falando especificamente de bancos de dados relacionais. Então, imagina que eu tenho a tabela pessoa, então eu tenho um person gateway e na hora que eu faço uma busca, eu tenho esse person gateway com todos os registros que eu preciso. E por isso que eu acabo simulando a tabela do banco de dados no formato de objeto para eu conseguir trabalhar. O ponto importante aqui que você tem que sempre tomar cuidado é em relação à utilização de uso de memória, porque se você traz objetos muito grandes, provavelmente você vai ter problemas com performance. É muito interessante também dizer, galera, que normalmente essas abordagens que a gente vê, tanto de row, table, row, data, gateway, e também como table, data, gateway, isso aí, hoje em dia, a gente vê pouco sendo utilizado honestamente. E você vai começar a entender por que quando a gente chegar em outros padrões mais para frente. Por outro lado, se você olhar, por exemplo, alguns frameworks, sei lá, um Zend Framework, por exemplo, ele utilizava muito esses tipos de padrão. um Zend Framework, por exemplo, ele utilizava muito esses tipos de padrão. E você vai ver que, infelizmente, por falta de conhecimento que muitos devs têm, eles acabam não implementando esses tipos de padrão em casos de uso que realmente esses padrões, eles realmente trazem uma bela de uma vantagem. Por isso que eu digo, toda vez que você aumenta o seu nível de repertório né você tem mais possibilidades para resolver casos de uso específicos tá então a gente tem esses dois formatos aqui que eu queria trazer para você entender tanto roll quanto o table. O grande ponto aqui é que ambos têm o objetivo de falar com o banco de dados. Maravilha? Então, vamos seguindo aí.