‫Instrutor: Até este
‫ponto, acabamos de escrever nosso código sem pensar
‫muito sobre a arquitetura de nosso aplicativo.
‫Não era realmente importante até agora, mas agora
‫que nosso aplicativo está realmente começando a crescer, precisamos começar
‫a nos preocupar
‫com a maneira como projetamos ou com a arquitetura de código.
‫E esta palestra será apenas uma breve
‫introdução à arquitetura back-end.
‫Começando com a arquitetura MVC.
‫Então, neste projeto,
‫vamos usar uma arquitetura amplamente
‫usada e conhecida chamada de modelo,
‫visualização, controlador ou MVC.
‫E existem
‫diferentes maneiras de implementar a arquitetura MVC,
‫algumas mais complexas do que
‫outras, mas vamos
‫implementá-la de uma forma muito direta aqui.
‫Eu só queria que você
‫soubesse que, se você pesquisar MVC no
‫Google, você o encontrará implementado de algumas maneiras diferentes.
‫Ok, de qualquer maneira, nesta arquitetura, a camada
‫de modelo se preocupa com
‫tudo sobre os dados dos aplicativos e a
‫lógica de negócios.
‫E aprenderemos o que a lógica de negócios significa
‫no próximo slide.
‫Em seguida, temos a camada de controlador
‫e a função dos controladores
‫é lidar com a solicitação da
‫aplicação, interagir com
‫os modelos e enviar respostas ao cliente.
‫E tudo isso é chamado de lógica do aplicativo.
‫Finalmente, a camada de visualização é
‫necessária se tivermos uma interface gráfica em nosso aplicativo.
‫Ou em outras palavras, se estivermos
‫construindo um site renderizado do lado do
‫servidor, como falamos antes.
‫Nesse caso, a camada de visualização consiste basicamente
‫nos templates usados para gerar
‫a visualização, ou seja, o site que iremos enviar de volta ao cliente.
‫E essa é a lógica de apresentação.
‫Por enquanto, estamos apenas construindo uma API,
‫então não estamos realmente preocupados com as visualizações ainda.
‫Isso é um pouco mais tarde no curso.
‫Portanto, usar um padrão ou uma arquitetura como essa nos
‫permite escrever um aplicativo mais modular, que
‫será muito mais fácil de manter em
‫escala, conforme necessário.
‫E poderíamos ir ainda mais
‫longe e adicionar mais camadas de abstração aqui.
‫Mas, neste tipo de aplicativo menor, a
‫arquitetura MVC é mais do que suficiente para nossas necessidades.
‫Agora, tudo isso pode parecer
‫um pouco abstrato, então vamos dar uma olhada no MVC no contexto
‫de nosso aplicativo e no ciclo de solicitação-resposta.
‫Como sempre, tudo começa com um pedido.
‫Essa solicitação atingirá um de nossos roteadores, porque
‫lembre-se de que temos vários roteadores.
‫Basicamente, um para
‫cada recurso, como tours, usuários etc.
‫Agora, o objetivo do roteador é delegar a
‫solicitação à função de
‫manipulador correta, que estará em um dos controladores.
‫E, novamente, haverá um controlador
‫para cada um de
‫nossos recursos, para manter essas diferentes partes do aplicativo bem separadas.
‫Então, dependendo da solicitação recebida, o controlador
‫pode precisar interagir com um dos
‫modelos, por exemplo, para
‫recuperar um
‫determinado documento do banco de dados
‫ou para criar um novo.
‫Mais uma vez, existe um arquivo de modelo para cada recurso.
‫Depois de obter os dados do
‫modelo, o controlador pode estar pronto para enviar de
‫volta uma resposta ao cliente, por exemplo, contendo esses dados.
‫Agora, caso desejemos realmente renderizar um site, há
‫mais uma etapa envolvida.
‫Nesse caso, depois de obter os dados do
‫modelo, o controlador
‫selecionará um dos modelos de visualização e injetará os dados nele.
‫Esse site renderizado será então enviado de
‫volta como resposta.
‫Na camada de visualização em um
‫aplicativo Express, geralmente há um modelo de visualização para cada página.
‫Como uma página de visão geral do
‫tour, uma página de detalhes do tour ou uma página de login.
‫No exemplo de nosso aplicativo mais recente, é claro.
‫Então, essa é uma visão ampla da arquitetura
‫que vamos implementar neste projeto.
‫Agora, para terminar, deixe-me entrar
‫em mais detalhes sobre o modelo e o controlador.
‫Portanto, um dos grandes objetivos do MVC é
‫separar a lógica de
‫negócios da lógica do aplicativo.
‫Você ouvirá sobre esses tipos de lógica o tempo
‫todo quando navegar no Stack
‫Overflow ou em algum site parecido.
‫Mas quais são esses tipos de lógica na verdade?
‫Bem, a diferença é um pouco opinativa, mas esta
‫é minha opinião sobre isso: então,
‫a lógica do aplicativo é todo o código que
‫se preocupa apenas com
‫a implementação do aplicativo e
‫não com o problema de negócios
‫subjacente que estamos tentando resolver com o aplicativo .
‫Como mostrar e vender
‫tours, administrar estoque em um
‫supermercado ou organizar uma biblioteca, por exemplo.
‫Portanto, novamente, a lógica do
‫aplicativo é a lógica que faz o aplicativo realmente funcionar.
‫Por exemplo, uma grande parte da lógica do aplicativo no
‫Express envolve o gerenciamento de solicitações e respostas.
‫Então, de certa forma, também podemos
‫dizer que a lógica do aplicativo é mais sobre coisas técnicas.
‫Além disso, se tivermos visualizações em nosso aplicativo,
‫a lógica do aplicativo servirá
‫como uma ponte entre o modelo e as camadas de
‫visualização, para que nunca misturemos a lógica
‫de negócios com a lógica de apresentação.
‫Tudo bem?
‫Agora, sobre a lógica
‫de negócios, é todo o código que realmente resolve o
‫problema de negócios que pretendemos resolver.
‫Digamos novamente que nosso objetivo é mostrar passeios aos clientes
‫e depois vendê-los.
‫E o código que está diretamente relacionado às regras de negócios, ao
‫modo como o negócio funciona
‫e às necessidades do negócio, é a lógica do negócio.
‫Agora, se isso ainda parece um pouco filosófico demais,
‫alguns exemplos no contexto de nosso aplicativo mais recente
‫estão criando novos passeios no banco de dados do aplicativo,
‫verificando se a senha de um usuário está correta quando ele faz login,
‫validando os dados de entrada do
‫usuário ou garantindo que apenas os usuários quem comprou um determinado
‫passeio pode avaliá-lo.
‫Portanto, tudo isso está relacionado ao próprio negócio e,
‫portanto, faz parte da lógica do negócio.
‫Agora, precisamos ter em mente
‫que a lógica do aplicativo e a
‫lógica do negócio são quase impossíveis de separar completamente e,
‫portanto, às vezes elas se sobrepõem.
‫Mas devemos nos esforçar
‫ao máximo para manter a lógica do aplicativo em
‫nossos controladores e a lógica de negócios em nossos modelos.
‫E há até mesmo essa
‫filosofia de modelos gordos, controladores finos,
‫que diz que
‫devemos descarregar o máximo de lógica possível nos
‫modelos, para manter os controladores o mais simples e enxutos possíveis.
‫Portanto, um modelo gordo terá tanta lógica de negócios
‫quanto pudermos descarregar para ele,
‫e um controlador fino terá o mínimo de lógica possível,
‫de forma que o
‫controlador seja principalmente para gerenciar as solicitações e respostas
‫do aplicativo.
‫OK?
‫Portanto, agora mantenha tudo isso em mente à
‫medida que avançamos e progredimos na construção de nossos aplicativos.