.NET: persistência de dados com MongoDB

Primeiros passos no MongoDB - Apresentação

Apresentando o curso e o instrutor

Olá! Sejam muito bem-vindos ao nosso curso de .NET Persistência com o MongoDB. Meu nome é Victorino Villa e serei o instrutor deste curso.

Audiodescrição: Victorino é um homem branco, de cabelo curto e barba grisalhos, veste uma camiseta preta. Ele está em um ambiente de escritório com uma iluminação azul ao fundo.

Introduzindo o conteúdo do curso

Neste curso, aprenderemos como integrar o MongoDB, um dos bancos de dados NoSQL mais populares do mercado, com aplicações desenvolvidas em C#. Abordaremos desde conceitos básicos de bancos NoSQL e modelagem de dados orientada a documentos, até a configuração completa do ambiente de trabalho e a implementação de rotinas completas de leitura, escrita, consultas avançadas, agregações e muito mais.

Durante o curso, montaremos juntos um projeto completo, como o mostrado na tela. Este será o nosso resultado final. Teremos vários programas práticos a serem implementados, cada um simulando uma situação real de interação entre o MongoDB e o C#.

Discutindo a importância do curso e suas aplicações práticas

Durante os exemplos práticos, discutiremos o desempenho, as melhores práticas e intercalaremos com um bate-papo conceitual sobre os comandos e a forma de trabalhar na interação entre C-Sharp e MongoDB. Este curso é importante para o mercado de trabalho, pois saber interagir o MongoDB com C-Sharp será um diferencial significativo, especialmente devido à crescente demanda por aplicações escaláveis, flexíveis e integradas à nuvem. Utilizaremos um MongoDB em uma instância de nuvem.

Concluindo e motivando os alunos

Ao final do curso, estaremos aptos a implementar soluções reais usando essas duas tecnologias, aumentando nossa empregabilidade e capacidade de inovar em novos projetos. Preparemos nosso ambiente, aproveitemos cada aula e vamos juntos transformar nossa carreira. Até o próximo vídeo.

Primeiros passos no MongoDB - Relação do MongoDB com o .NET

Introduzindo o curso de .NET com MongoDB

Vamos iniciar o curso de .NET com MongoDB. Acreditamos que todos já devem ter ouvido falar do MongoDB. Trata-se de um banco de dados NoSQL. O termo NoSQL, ao contrário do que muitos pensam, não significa "Não SQL", mas sim "Not Only SQL", ou seja, "não apenas SQL". Em um banco de dados NoSQL, podemos ter diferentes estruturas de armazenamento. No caso específico do MongoDB, ele armazena documentos no formato JSON. Se alguém não está familiarizado com o termo JSON, não se preocupe, pois falaremos bastante sobre ele.

Existem outros tipos de bancos de dados NoSQL, como aqueles que utilizam uma estrutura de chave-valor, bancos NoSQL colunares e bancos NoSQL orientados a grafos. Cada um desses modelos oferece diferentes formas de armazenar dados. A maneira como gravamos dados em um banco NoSQL é bem diferente do modelo relacional ao qual estamos acostumados. A linguagem utilizada para criar estruturas e realizar consultas em NoSQL não é o SQL tradicional.

Explicando o surgimento dos bancos de dados NoSQL

Por que surgiram os bancos de dados NoSQL? Afinal, os bancos de dados SQL são ideais para modelar processos e empresas. Os bancos SQL foram desenvolvidos com base no modelo relacional, criado nos anos 70, que substituiu os bancos de dados sequenciais da época. Esses bancos sequenciais eram utilizados em grandes computadores, os mainframes, que ocupavam salas inteiras e eram extremamente lentos comparados aos computadores atuais.

Os bancos de dados relacionais que utilizam SQL são excelentes para modelar processos com lógica clara. Por exemplo, em uma empresa, o processo de venda gera um pagamento, que resulta em uma baixa de estoque e, posteriormente, em uma entrega. Esse processo é bem definido e repetitivo.

Enfrentando desafios com o surgimento da internet e redes sociais

Com o surgimento da internet e das redes sociais, surgiu um grande desafio: como modelar processos extremamente dinâmicos em um tipo de banco de dados projetado para processos rígidos? Em uma rede social como o Twitter, atualmente conhecido como X, temos um post que pode gerar um comentário, que pode gerar uma resposta, que pode ou não vir de alguém que segue o usuário, além de curtidas e notificações. Em uma estrutura de rede social, os dados são extremamente caóticos, sem uma lógica fixa.

Inicialmente, as redes sociais foram modeladas usando bancos de dados relacionais. No entanto, com o aumento dos usuários, controlar o fluxo de dados tornou-se extremamente difícil. As consultas ficaram lentas e complicadas. Foi então que os engenheiros buscaram novas formas de armazenamento de dados, inspirando-se no desenvolvimento de software, especificamente na Programação Orientada a Objetos (POO).

Explorando a programação orientada a objetos

A ideia da POO surgiu nos anos 60 e se popularizou nos anos 80, com as primeiras linguagens realmente orientadas a objetos. Linguagens como Python, Java e C# adotaram a Programação Orientada a Objetos. Atualmente, toda linguagem moderna utiliza a POO.

No POO (Programação Orientada a Objetos), criamos o que chamamos de uma classe, ou seja, um objeto que possui atributos e comportamentos, que denominamos métodos. Temos conceitos associados ao POO, como herança, polimorfismo, encapsulamento e abstração. O ponto importante aqui é que podemos serializar e desserializar essas classes de objetos.

Demonstrando a serialização e desserialização com JSON

Serializar significa transformar o conteúdo da instância do objeto, da classe, em JSON. JSON é uma representação textual de um objeto. O inverso, desserializar, é transformar um JSON em uma classe novamente. Assim, se conseguimos armazenar este JSON dentro de um banco de dados, estaremos gravando o estado do objeto dentro do próprio banco de dados. O MongoDB faz exatamente isso: guarda os objetos como JSON. Quando queremos buscar a informação do banco de dados, buscamos o JSON, desserializamos e o trazemos de volta como uma classe dentro da nossa linguagem de programação, no nosso caso, dentro do .NET.

Para ilustrar isso, vamos ver um exemplo de uma classe em C#. Esta classe é chamada Noticia e possui algumas propriedades básicas:

public class Noticia {
    public string Titulo { get; set; }
    public string Texto { get; set; }
    public string Autor { get; set; }
    public DateTime DataPublicacao { get; set; }
}

Esta classe Noticia possui as propriedades Titulo, Texto, Autor e DataPublicacao. Título, texto e autor são do tipo String, e a data da publicação é do tipo DateTime.

Armazenando e consultando JSON no MongoDB

Se pegarmos este objeto e o serializarmos, ele se tornará um código JSON, como o mostrado a seguir:

{
    "Titulo": "Novidade no mundo .NET",
    "Texto": "Saiu uma nova versão do .NET 6...",
    "Autor": "Victorino",
    "DataPublicacao": "2024-06-10T13:00:00Z"
}

Este código JSON é a representação daquela classe. Podemos armazenar este código JSON dentro do MongoDB, representando o estado da classe no momento em que foi salva.

O JSON é um texto grande com marcações. Poderíamos pensar em criar um campo Text, Varchar ou Blob, dependendo do banco de dados relacional, para armazenar o JSON diretamente. No entanto, isso não é tão simples, pois, em um banco de dados relacional, criar um campo Text muito grande e gravar o JSON usando SQL padrão dificulta a aplicação de filtros, por exemplo, para buscar todos os posts curtidos por uma pessoa específica ou, no nosso exemplo, todas as notícias escritas por um determinado jornalista. O valor desse filtro está armazenado dentro do JSON, mas em algum lugar lá dentro.

Hoje em dia, bancos de dados relacionais como Oracle, SQL Server, Postgres ou MySQL já suportam dados no formato JSON. Esses bancos relacionais fizeram isso porque estavam perdendo espaço para os bancos de dados NoSQL, que foram feitos exclusivamente para armazenar JSONs. O MongoDB é um desses bancos, feito para armazenar JSONs. Dentro do MongoDB, o JSON pode ser facilmente consultado, aplicando filtros, efetuando consultas, usando condições de seleção, agrupando dados dentro do JSON e aplicando fórmulas diretamente na estrutura do JSON. O MongoDB se integra perfeitamente com uma linguagem de programação orientada a objetos, como o .NET. No nosso caso específico, utilizaremos o C#, que será a linguagem de programação com a qual trabalharemos.

No C#, modelaremos nosso modelo orientado a objetos e interagiremos com o MongoDB como base de dados para armazenar esta classe. Vamos encerrar o vídeo por aqui e, no próximo, veremos um exemplo prático que mostra a complexidade de armazenar dados, baseados, por exemplo, em um site de notícias da internet. Muito obrigado e até o próximo vídeo.

Primeiros passos no MongoDB - Complexidade no armazenamento do dado

Analisando a estrutura dinâmica do site de notícias

Vamos analisar o site de notícias exibido na tela. Imagine que precisamos armazenar os dados dessa notícia em um banco de dados. O objetivo é ter um site dinâmico, onde as informações contidas na página estejam dentro de um banco de dados. Essa página foi construída em HTML, mas não de forma fixa e rígida; ela foi criada dinamicamente com base nas informações armazenadas em um banco de dados. Assim, o framework de back-end e front-end atuam em conjunto para buscar as informações da base de dados e montar a página de forma dinâmica.

Se o repórter que escreveu a notícia quiser adicionar mais informações, ou se um usuário quiser adicionar um comentário, essas informações extras serão incluídas no banco de dados. Quando atualizarmos a tela no navegador, a página será redesenhada com as novas informações.

Modelando o banco de dados relacional

Suponhamos que desejamos modelar esse banco de dados em um banco de dados relacional. Precisaríamos criar diversas tabelas, como a tabela de notícias, a tabela de autores, a tabela de comentários, e a tabela de assuntos ou tags. Seria necessário criar relacionamentos entre essas tabelas, como relacionamentos de 1 para 1, 1 para n, e n para m. Poderíamos ter relacionamentos recursivos, como um comentário associado a uma notícia, mas também um comentário de um comentário. Todos esses relacionamentos precisariam de chaves estrangeiras para garantir a integridade, e chaves primárias para evitar dados repetidos. A integridade garantiria, por exemplo, que apenas usuários registrados pudessem comentar em uma notícia, e que os comentários estivessem associados a assuntos existentes.

Aqui temos uma representação de um banco de dados que poderia armazenar os dados da notícia. Embora a representação não esteja perfeita, temos seis tabelas e um relacionamento de 1 para n entre notícias e comentários, um relacionamento de n para m entre notícias e jornalistas, e outro de n para m entre notícias e tags.

Exemplificando consultas SQL

Para ilustrar como seria uma consulta SQL para buscar notícias de esportes escritas por uma jornalista específica, podemos usar o seguinte exemplo:

SELECT n.titulo, n.texto, j.nome, c.comentario, c.curtidas
FROM noticias n
JOIN jornalistas_noticias jn ON n.id = jn.id_noticia
JOIN jornalistas j ON j.id = jn.id_jornalista
LEFT JOIN comentarios c ON c.id_noticia = n.id
JOIN tags t ON t.id_noticia = n.id
WHERE t.nome = 'esporte'
AND YEAR(n.data_publicacao) = 2023
AND j.nome = 'Maria'
ORDER BY c.curtidas DESC

Agora, suponhamos que tudo esteja funcionando e nos pedem para mudar uma regra de negócio. Por exemplo, toda notícia agora precisa ter uma foto ou um vídeo armazenado. Teríamos que acrescentar uma nova tabela ao banco de dados para armazenar os dados desse anexo, modificar alguns relacionamentos, recriar novas integridades e adicionar novos índices para melhorar as pesquisas. Se quisermos consultar todas as notícias sobre esportes, precisaríamos fazer uma consulta SQL, que poderia se tornar mais complexa com a adição de novas tabelas e joins, exigindo modificações nas consultas SQL já existentes.

Representando dados em JSON

Vamos pensar fora da caixa e tentar representar a notícia não apenas em um banco de dados relacional, mas em um JSON. Como seria esse JSON? Ele teria a representação principal da notícia, um conjunto de assuntos em um vetor, pois a notícia pode estar associada a vários assuntos. Poderíamos ter um ou mais jornalistas associados à notícia, e um ou mais comentários. A estrutura de comentários seria mais complexa, mas estaria dentro do JSON em um vetor ou array.

Um exemplo de como esse JSON poderia ser estruturado é o seguinte:

{
    "titulo": "Brasil bate Equador",
    "texto": "No Maracanã, Brasil vence por 2 a 0...",
    "data_publicacao": "2023-08-10T15:32:00Z",
    "tags": ["esporte", "brasil"],
    "jornalistas": [
        { "nome": "Maria" },
        { "nome": "João" }
    ],
    "comentarios": [
        {
            "comentario": "Grande jogo!",
            "curtidas": 15,
            "usuario": "Carlos",
            "data": "2023-08-10T18:45:00Z"
        },
        {
            "comentario": "Poderiam ter feito mais gols.",
            "curtidas": 8,
            "usuario": "Ana",
            "data": "2023-08-10T19:00:00Z"
        }
    ]
}

Com esse JSON representando a notícia, poderíamos salvá-lo no MongoDB como uma única linha de uma coleção, contendo todo o JSON que representa a notícia.

Comparando bancos de dados relacionais e MongoDB

Vamos lembrar que uma coleção no MongoDB equivale a uma tabela. Ou seja, toda a estrutura de dados da notícia, que em um banco de dados relacional exigiria várias tabelas com relacionamentos, no MongoDB é armazenada em apenas uma tabela simples, que teria a representação JSON da notícia. Como temos um back-end que se relaciona com o banco de dados, poderíamos obter nesse back-end, que seria em C#, .NET, uma classe equivalente a este JSON. Essa classe seria mais ou menos assim:

using System;
using System.Collections.Generic;

public class Noticia
{
    public string Titulo { get; set; }
    public string Texto { get; set; }
    public DateTime DataPublicacao { get; set; }
    public List<string> Tags { get; set; }
    public List<Jornalista> Jornalistas { get; set; }
    public List<Comentario> Comentarios { get; set; }
}

public class Jornalista
{
    public string Nome { get; set; }
}

public class Comentario
{
    public string ComentarioTexto { get; set; }
    public int Curtidas { get; set; }
    public string Usuario { get; set; }
    public DateTime Data { get; set; }
}

Através de serialização, gravaríamos dentro do MongoDB um JSON em uma única linha.

Adicionando novos elementos no MongoDB

Como seria a consulta no MongoDB para obter todas as notícias de esportes? Teríamos uma consulta mais simples, uma representação do dado mais simples, apenas em uma única tabela. A grande vantagem do MongoDB não está apenas na simplicidade da representação, mas na flexibilidade da mudança da estrutura. Suponhamos que agora precisemos acrescentar mais uma entidade no nosso modelo. Vamos falar novamente daquela entidade mencionada no início do vídeo, os anexos. Precisamos agora ter uma representação dos anexos associados à notícia, que pode ser um vídeo ou uma foto.

No modelo relacional, teríamos que criar uma nova tabela. Por exemplo, criaríamos essa nova tabela de anexos, estabeleceríamos mais um relacionamento com a tabela de notícias e, por fim, teríamos que mudar parcialmente a estrutura. Seria necessário um script para alterar toda a estrutura do banco, preencher as notícias antigas para permitir que tenham um anexo em uma tabela separada, evitando falhas de integridade. Isso exigiria parar o banco em produção, mexer na sua estrutura e recarregar as tabelas. Imagine se esse banco fosse gigante; a probabilidade de ocorrer um problema seria altíssima.

Já no MongoDB, basta alterarmos a classe, adicionando o atributo de anexo no objeto notícia, no nosso programa C#. Teríamos mais uma propriedade, que seria uma lista de anexos, e a representação da classe anexo:

using System;
using System.Collections.Generic;

public class Noticia
{
    public string Titulo { get; set; }
    public string Texto { get; set; }
    public DateTime DataPublicacao { get; set; }
    public List<string> Tags { get; set; }
    public List<Jornalista> Jornalistas { get; set; }
    public List<Comentario> Comentarios { get; set; }
    public List<Anexo> Anexos { get; set; } // Nova propriedade para anexos
}

public class Jornalista
{
    public string Nome { get; set; }
}

public class Comentario
{
    public string ComentarioTexto { get; set; }
    public int Curtidas { get; set; }
    public string Usuario { get; set; }
    public DateTime Data { get; set; }
}

public class Anexo
{
    public string NomeArquivo { get; set; }
    public string Url { get; set; }
    public long Tamanho { get; set; }
    public string Tipo { get; set; }
}

Quando serializássemos essa classe, ela geraria um JSON com uma nova estrutura. Teríamos, na propriedade principal da notícia, o conjunto de anexos.

Explorando a flexibilidade do MongoDB

Como fica essa mudança dentro do MongoDB? A vantagem é que podemos armazenar esse novo JSON no MongoDB dentro da mesma coleção onde estão os antigos, ou seja, na mesma tabela. Não precisamos alterar nada no banco, criar uma nova estrutura ou redesenhar os JSONs antigos. No MongoDB, é permitido que tenhamos, na mesma coleção, estruturas de JSONs diferentes representando a mesma classe de objeto. Nada seria mudado. Passaríamos apenas a armazenar o novo JSON na tabela já existente, sem mexer nos outros registros.

Vamos ver algumas comparações entre os dois ambientes. No relacional, alterar a estrutura pode ser um desafio, pois precisamos criar scripts, fazer migrações de dados, adaptar consultas, e o risco de quebrar o sistema aumenta muito com essas mudanças. Já no MongoDB, basta adicionar um novo campo na classe, criar novos JSONs e atualizar esse JSON na mesma estrutura existente. No MongoDB, não há impacto em começar a criar, dentro da mesma coleção, JSONs diferentes junto com JSONs antigos. O acesso ao dado fica mais direto e rápido para outros tipos de consultas.

Considerações finais sobre a flexibilidade e responsabilidade no MongoDB

Enfim, temos aqui algumas informações pertinentes sobre os dois ambientes, a dificuldade de um e a facilidade do outro ao mudar a estrutura. Porém, essa flexibilidade exige responsabilidade. No MongoDB, é necessário padronizar e documentar bem o formato dos documentos, já que não há representação da estrutura do dado. No MongoDB, colocamos o JSON ali dentro e fim de papo. No banco de dados relacional, a estrutura do dado faz parte do desenho das tabelas. No MongoDB, não. Não temos isso nos metadados dentro do banco. Portanto, é importante documentar bem o formato dos documentos para que a aplicação, na classe, saiba lidar com diferentes versões e formatos do dado. Sem esse cuidado, podemos acabar com documentos muito diferentes entre si, dificultando a manutenção do sistema.

Vamos parar por aqui e, no próximo vídeo, discutiremos como será nosso ambiente de trabalho no curso. Até mais!

Sobre o curso .NET: persistência de dados com MongoDB

O curso .NET: persistência de dados com MongoDB possui 684 minutos de vídeos, em um total de 102 atividades. Gostou? Conheça nossos outros cursos de .NET em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• capitulo