Parte 2. Vamos falar um pouco sobre arquitetura de software

Este material faz parte da série “ Introdução ao Desenvolvimento Empresarial ”. A primeira parte sobre a rede está aqui . A arquitetura de software é a estrutura com base na qual um aplicativo é criado e os módulos e componentes de todo o programa interagem. Os programadores vêm tentando criar uma boa arquitetura há muito tempo, então não é surpreendente que agora conheçamos muitos padrões de arquitetura. Você precisa entendê-los: quando você escreve uma aplicação web, o problema de arquitetura se torna agudo, porque há mais componentes e módulos nela do que em uma aplicação normal. Um padrão arquitetônico é uma maneira já pensada de resolver algum problema de design de software. Você provavelmente já encontrou padrões de design como Factory Method, Abstract Factory, Builder, Prototype, Singleton e talvez outros. Eles são usados ​​simplesmente para escrever código, criar classes e planejar como interagem. Os padrões arquitetônicos são usados ​​em um nível mais alto de abstração - ao planejar a interação do usuário do aplicativo com o servidor, dados e outros componentes do projeto. Vamos dar uma olhada rápida em alguns modelos e como usá-los.

Arquitetura cliente-servidor

Pelo nome tem-se a impressão de que tudo neste tema é simples e claro. Mas vamos esclarecer alguns pontos para que quando você começar a estudar o Spring condicional você entenda exatamente do que estamos falando. Digamos que você escreveu um chat e você e seu amigo começaram a usá-lo. Uma opção simples é possível aqui - vocês enviam uma mensagem um para o outro diretamente pela Internet usando endereços IP que você conhece: A princípio pode parecer que tudo está funcionando bem, até que outro amigo seu apareça com a pergunta: “Por que não você não me adiciona ao seu bate-papo? E quando você decide adicionar um amigo em comum ao chat, você se depara com um problema arquitetônico: cada usuário do chat precisa atualizar informações sobre o número de usuários, adicionar o endereço IP do novo usuário. E ao enviar uma mensagem, ela deverá ser entregue a todos os participantes. Estes são os problemas mais óbvios que surgirão. Muito mais problemas estarão ocultos no próprio código. Para evitá-los, é necessário utilizar um servidor que armazene todas as informações sobre os usuários e conheça seus endereços. A mensagem só precisará ser enviada ao servidor. E ele, por sua vez, enviará a mensagem para todos os destinatários. Ao decidir adicionar um servidor ao seu chat, você começará a construir uma arquitetura cliente-servidor.

Componentes da arquitetura cliente-servidor

Vamos descobrir o que ela é. A arquitetura cliente-servidor é um padrão de design, a base para a criação de aplicações web. Esta arquitetura consiste em três componentes:

1. Cliente - pelo nome fica claro que se trata de um usuário de um serviço (aplicação web) que entra em contato com o servidor para obter alguma informação.

2. Servidor é o local onde seu aplicativo da web ou parte do servidor está localizado. Ele possui as informações necessárias sobre os usuários ou pode solicitá-las. Além disso, quando um cliente entra em contato, o servidor retorna as informações solicitadas.

3. A rede é simples: garante a troca de informações entre o cliente e o servidor.

O servidor pode processar um grande número de solicitações de diferentes usuários. Ou seja, podem ser muitos clientes, e se eles precisarem trocar informações entre si, isso terá que ser feito através do servidor. Assim, o servidor recebe mais uma função adicional - controle de tráfego. Se estamos falando do chat multiusuário que criamos, todo o código do programa será composto por dois módulos:

• cliente - contém uma interface gráfica para autorização, envio/recebimento de mensagens;

• lado do servidor - um aplicativo da web hospedado em um servidor e que recebe mensagens dos usuários, as processa e as envia aos destinatários.

Quando queremos ver informações úteis (ou não tão úteis) na Internet, abrimos um navegador, inserimos uma consulta na barra de pesquisa e, em resposta, recebemos informações do mecanismo de pesquisa. Nessa cadeia, o navegador é nosso cliente. Envia ao servidor uma solicitação com informações sobre o que procuramos. O servidor processa a solicitação, encontra os resultados mais relevantes, empacota-os em um formato compreensível para o navegador (cliente) e os envia de volta. Em serviços complexos como motores de busca, pode haver muitos servidores. Por exemplo, um servidor de autorização, um servidor para busca de informações, um servidor para gerar uma resposta. Mas o cliente nada sabe sobre isso: para ele o servidor é algo unificado. O cliente conhece apenas o ponto de entrada, ou seja, o endereço do servidor para o qual deseja enviar a solicitação. Vamos relembrar o aplicativo que vimos na parte anterior - para monitorar em tempo real a temperatura média do ar em todos os países. Sua arquitetura será mais ou menos assim: Nosso aplicativo está localizado em um servidor. Digamos que a cada cinco segundos ele envia solicitações aos servidores dos centros hidrometeorológicos locais, recebe deles informações sobre a temperatura de um determinado país e armazena essas informações. Quando um cliente nos contacta com um pedido para “ver a temperatura actual do ar no mundo”, devolvemos as últimas informações armazenadas, ordenadas por país. Assim, nossa aplicação é tanto servidor (quando processa solicitações de usuários) quanto cliente (quando recebe informações de outros servidores). Uma arquitetura cliente-servidor simples é usada muito raramente e apenas para aplicações muito simples. Para projetos realmente grandes e complexos, são utilizados diferentes tipos de arquiteturas, com as quais você se familiarizará mais no futuro. Por enquanto, vamos examinar um modelo muito semelhante ao modelo cliente-servidor.

Arquitetura de três camadas

Este é um padrão arquitetônico que apresenta um terceiro player: o data warehouse . Ao usar esse padrão, os três níveis são geralmente chamados de camadas:

1. A camada do cliente é a interface do usuário. Pode ser um navegador da web para o qual as páginas HTML são enviadas ou um aplicativo GUI escrito em JavaFX. O principal é que com sua ajuda o usuário possa enviar solicitações ao servidor e processar suas respostas.

2. A camada lógica é o servidor no qual as solicitações/respostas são processadas. Muitas vezes também é chamada de camada do servidor. Todas as operações lógicas também acontecem aqui: cálculos matemáticos, operações de dados, chamadas para outros serviços ou armazenamento de dados.

3. A camada de dados é o servidor de banco de dados: nosso servidor o acessa. Esta camada armazena todas as informações necessárias que o aplicativo utiliza durante a operação.

Assim, o nosso servidor assume todas as obrigações de acesso aos dados, não permitindo ao utilizador aceder diretamente aos mesmos.

Benefícios de uma arquitetura de três camadas

Usando essa arquitetura, obtemos muitas vantagens, incluindo:

1. A capacidade de construir proteção contra injeções de SQL é um ataque ao servidor no qual o código SQL é transmitido e, quando esse código é executado, o invasor pode afetar nosso banco de dados.

2. Delimitação dos dados aos quais queremos regular o acesso dos utilizadores.

3. Capacidade de modificar dados antes de enviá-los ao cliente.

4. Escalabilidade - a capacidade de expandir nossa aplicação em vários servidores que utilizarão o mesmo banco de dados.

5. Menos requisitos para a qualidade da conexão do usuário. Ao gerar uma resposta no servidor, muitas vezes pegamos muitas informações diferentes do banco de dados, formatamos, deixando apenas o que o usuário precisa. Desta forma reduzimos a quantidade de informação que enviamos em resposta ao cliente.

Com que frequência você deve usar padrões arquitetônicos?

Se você estiver familiarizado, digamos, com o padrão de design Factory Method , provavelmente já se perguntou quando usá-lo. Às vezes é difícil decidir o que fazer: criar um objeto usando o operador new ou usando um método de fábrica. Mas com o tempo, a compreensão vem. Com padrões arquitetônicos, as coisas são um pouco diferentes. As estruturas corporativas são projetadas para que o programador as utilize para criar um projeto baseado em algum padrão geralmente aceito. Portanto, antes de aprender o Spring Framework, você definitivamente precisa entender o que são arquitetura cliente-servidor, arquitetura de três camadas e arquitetura MVC. Não se preocupe: falaremos sobre arquitetura MVC mais tarde. Parte 1. O que você precisa saber antes de aprender Spring e JavaEE Parte 3. Protocolos HTTP/HTTPS Parte 4. Noções básicas de Maven Parte 5. Servlets. Escrevendo um aplicativo Web simples Parte 6. Contêineres de servlet Parte 7. Apresentando o padrão MVC (Model-View-Controller) Parte 8. Escrevendo um pequeno aplicativo Spring-Boot