Parte 2. Vamos falar um pouco sobre arquitetura de software

Este material faz parte da série "Introdução ao Desenvolvimento Corporativo" . A primeira parte, sobre networking, está aqui . Arquitetura de software refere-se à estrutura criada dentro de um aplicativo, ou seja, todos os módulos e componentes do programa e como eles interagem. Os programadores trabalham em boas arquiteturas há muito tempo, então não é surpresa que tenhamos ouvido falar de muitos padrões de arquitetura. Você precisa entendê-los: ao escrever um aplicativo da Web, é fundamental criar uma boa arquitetura, porque um aplicativo da Web possui mais componentes e módulos do que um aplicativo comum. Um padrão arquitetônicoé uma maneira inteligente de resolver algum problema de design de software. Você provavelmente já se deparou com padrões de projeto como método de fábrica, fábrica abstrata, construtor, protótipo, singleton e possivelmente outros. Nós os usamos ao escrever código, criar classes e planejar como as classes irão interagir. Os padrões de arquitetura são usados ​​em um nível mais alto de abstração, ao planejar a interação do usuário com servidores, dados e outros componentes. Vamos dar uma olhada rápida em alguns padrões e como usá-los.

Arquitetura cliente-servidor

O nome cria a impressão de que tudo nesse padrão é simples e claro. Mas vamos esclarecer alguns pontos, para que quando você começar a estudar Spring você entenda do que estamos falando. Digamos que você tenha criado um aplicativo de bate-papo e você e um amigo comecem a usá-lo. Você poderia adotar uma abordagem muito simples, enviando mensagens entre si diretamente pela Internet usando endereços IP conhecidos: No início, tudo aparentemente funciona bem até que outro de seus amigos peça para entrar no chat. Portanto, quando você decide adicionar seu amigo em comum ao bate-papo, enfrenta um problema de arquitetura: para cada participante do bate-papo, você precisa fornecer informações atualizadas sobre o número de usuários e o endereço IP de novos usuários. E quando uma mensagem é enviada, ela precisa ser entregue a todos os participantes. Esses são os problemas mais óbvios que surgirão. Outro monte de problemas estará oculto no próprio código. Para evitá-los, você precisa usar um servidor, que armazenará todas as informações sobre os usuários, incluindo seus endereços. As mensagens só precisam ser enviadas para o servidor. Ele, por sua vez, envia mensagens para cada um dos destinatários. Ao decidir adicionar uma parte do servidor ao seu aplicativo de bate-papo, você está começando a construir uma arquitetura cliente-servidor.

Componentes da arquitetura cliente-servidor

Vamos ver do que se trata. Uma arquitetura cliente-servidor é um padrão de design usado para criar aplicativos da web. Esta arquitetura consiste em três componentes:

1. Cliente — Pelo nome podemos perceber que este componente utiliza algum serviço (a aplicação web), entrando em contato com um servidor para solicitar alguma informação.

2. Servidor — É aqui que seu aplicativo da Web ou a parte do servidor dele está localizado. Ele armazena as informações necessárias do usuário ou pode solicitá-las. Além disso, quando um cliente envia uma solicitação, é o servidor que retorna as informações solicitadas.

3. Rede — Esta parte é simples. Facilita a troca de informações entre o cliente e o servidor.

O servidor pode lidar com um grande número de solicitações de diferentes usuários. Isso significa que pode haver muitos clientes. Se eles precisam trocar informações entre si, isso tem que acontecer por meio do servidor. Assim, o servidor tem outra função: controle de tráfego. No que diz respeito ao nosso programa de bate-papo multiusuário, todo o aplicativo será composto por dois módulos:

• um módulo cliente — contém uma interface gráfica para entrar e enviar/receber mensagens

• um módulo de servidor — um aplicativo da web que é hospedado em um servidor e recebe mensagens de usuários, processa-as e as envia aos destinatários

Quando queremos ver informações úteis (ou não muito úteis) na Internet, abrimos um navegador, inserimos uma consulta na barra de pesquisa e obtemos informações do mecanismo de pesquisa como resposta. Nessa cadeia, o navegador é o cliente. Ele envia uma requisição com informações sobre o que estamos procurando para o servidor. O servidor processa a solicitação, encontra os resultados mais relevantes, os empacota em um formato que o navegador (cliente) possa entender e os envia de volta. Serviços complexos, como mecanismos de pesquisa, podem ter muitos servidores. Por exemplo, um servidor de autorização, um servidor para encontrar informações, um servidor para gerar a resposta, etc. Mas o cliente não sabe e não se preocupa com nada disso: para o cliente, o servidor é uma entidade unificada. O cliente só conhece o ponto de entrada, ou seja, o endereço do servidor para o qual as solicitações devem ser enviadas. Lembre-se do aplicativo que examinamos ema parte anterior desta série . Era para monitorar a temperatura média do ar em todos os países em tempo real. Sua arquitetura é mais ou menos assim: Nosso aplicativo está localizado no servidor. Digamos que a cada cinco segundos ele envie requisições para servidores operados por estações meteorológicas locais, receba dos servidores informações de temperatura de um determinado país e armazene essas informações. Quando o cliente nos pede para "ver a temperatura atual do ar no mundo", retornamos as informações armazenadas mais recentemente, classificadas por país. Assim, nosso aplicativo atua tanto como servidor (quando processa as solicitações dos usuários) quanto como cliente (quando recebe informações de outros servidores). Uma arquitetura cliente-servidor simples é usada muito raramente e apenas para aplicativos muito simples. Para projetos realmente grandes e complexos, usamos diferentes arquiteturas, que você conhecerá no futuro. Agora vamos ver um modelo muito semelhante à arquitetura cliente-servidor.

Arquitetura de três camadas

Este é um padrão de arquitetura que apresenta um terceiro módulo — armazenamento de dados . Nesse padrão, os três níveis são geralmente chamados de camadas ou camadas:

1. A camada do cliente é a interface do usuário, também chamada de camada de apresentação. Pode ser um navegador da Web que recebe páginas HTML ou uma interface gráfica do usuário escrita usando JavaFX. O principal é que esta camada permite que o usuário envie solicitações ao servidor e processe suas respostas.

2. A camada lógica é o servidor que processa solicitações/respostas. Freqüentemente, também é chamada de camada do servidor. É também aqui que ocorrem todas as operações lógicas: cálculos matemáticos, operações de dados, chamadas para outros serviços ou armazenamento de dados, etc.

3. A camada de dados é o servidor de banco de dados: nosso servidor interage com ela. Essa camada armazena todas as informações necessárias para o funcionamento do aplicativo.

Assim, nosso servidor assume toda a responsabilidade pelo acesso aos dados e não permite o acesso direto do usuário.

Vantagens de uma arquitetura de três camadas

Uma arquitetura como esta nos dá muitas vantagens, incluindo:

1. A capacidade de proteger contra injeção de SQL (este é um ataque a um servidor; envolve o envio de código SQL que, quando executado, permite que um invasor afete nosso banco de dados).

2. Separação dos dados aos quais queremos controlar o acesso do usuário.

3. A capacidade de modificar os dados antes de enviá-los ao cliente.

4. Escalabilidade (a capacidade de expandir nosso aplicativo para vários servidores que usarão o mesmo banco de dados.

5. Requisitos menos rigorosos sobre a qualidade das conexões do usuário. Ao gerar uma resposta no servidor, muitas vezes pegamos muitas informações diferentes de um banco de dados e formatamos, deixando apenas o que o usuário precisa. Isso reduz a quantidade de informações que enviamos em nossa resposta ao cliente.

Com que frequência os padrões de arquitetura devem ser usados?

Se você estiver familiarizado, digamos, com o padrão de design do método de fábrica , 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. As coisas são um pouco diferentes quando se trata de padrões arquitetônicos. As estruturas corporativas são projetadas para permitir que um programador crie um projeto com base em algum padrão geralmente aceito. Portanto, antes de aprender o Spring Framework, você definitivamente deve entender a arquitetura cliente-servidor, a arquitetura de três camadas e a arquitetura MVC. Não se preocupe: ainda falaremos sobre a arquitetura MVC. Parte 3. HTTP/HTTPS Parte 4. O básico do Maven Parte 5. Servlets e a API Java Servlet. Escrevendo um aplicativo Web simples Parte 6. Contêineres de servlet Parte 7. Apresentando o padrão MVC (Model-View-Controller)