1.

​ A evolução dos serviços

Era uma vez empresas que adotaram em massa um tal de Java. Ele conversava
com qualquer banco de dados e até mainframe, fazia transação distribuída e tornava
qualquer plataforma confiável para executar os seus sistemas. Depois do décimo sistema
feito por diferentes equipes, foi descoberto que todos eles tinham um mesmo cadastro de
clientes. O que começou a surgir nessas empresas foi o velho problema do
reaproveitamento de código.
Que tal isolar essa parte comum em um sistema único?
Assim, na virada do século, os serviços (internos e externos) começaram a usar um
padrão de comunicação via XML, chamado Simple Object Protocol (SOAP) ou, em
português, protocolo de acesso a objetos simples. Com ele, os sistemas começaram a
trocar informações, inclusive de diferentes linguagens e sistemas operacionais. Foi sem
dúvida uma revolução.
Começava a era da arquitetura orientada a serviços (SOA), que padronizava essa
comunicação entre os diferentes serviços.
O problema do padrão SOAP e a sua complexidade em fazer qualquer coisa, como, por
exemplo, realizar um serviço de consulta que retorne um valor simples. Isso tem muita
abstração envolvida, com servidor de um lado e obrigatoriamente um cliente do serviço do
outro, trafegando XML para ambos os lados. E tudo isso em cima do protocolo usado na
internet (HTTP).
No decorrer do tempo, muitos serviços SOAP, usados por vários
sistemas, começaram a aparecer rapidamente como a principal
causa de lentidão, obrigando os programadores a procurar
alternativas, como trocar o serviço SOAP por um acesso direto ao
banco de dados ou a um servidor Active Directory. Com esse
cenário, Roy Thomas, um dos fundadores do projeto Apache HTTP,
defendeu uma tese de doutorado apresentando uma alternativa bem
simples: o famoso Representational State Transfer (Transferência
de Estado Representacional), ou simplesmente REST. Essa simples alternativa ao SOAP
aproveita os métodos existentes no protocolo HTTP para fazer as operações mais comuns
existentes nos serviços, como busca e cadastro. Assim, por sua simplicidade e rapidez,
esse padrão foi rapidamente adotado pelo mercado.

​
Mesmo com os serviços REST, as aplicações continuam a empacotar todas as
funcionalidades em um só lugar, sendo classificadas como aplicações monolíticas. Fazendo
uma analogia de funcionalidade com um brinquedo, a aplicação sempre oferece a mesma
quantidade de brinquedos, independente da demanda. Em um cenários com muitas
crianças que só brincam com bonecas, sobrarão muitos aviões.
 Para resolver esse problema, destaca-se um subconjunto da arquitetura SOA
chamado microsserviços (microservices), que abraça a solução REST com o objetivo de
fornecer uma solução separada e independente para um problema.

O ideal de uma aplicação é separar suas

funcionalidades e se adequar ao cenário. Com o
conceito de microsserviços, cada funcionalidade é
independente e podemos crescer a sua quantidade
conforme a demanda de nosso cenário.

Agora, conforme a demanda das crianças, podemos

oferecer brinquedos sem que nada sobre.
2.​ O que é Java Spring Boot?
O Java Spring Framework (JSF) é um framework bastante conhecido de nível empresarial,
de software livre, para criar aplicativos independentes de nível de produção que são
executados na Java Virtual Machine (JVM).

O Java Spring Boot (ou apenas Spring Boot) é uma ferramenta que facilita e agiliza o
desenvolvimento de aplicações web e de microsserviços com o Spring Framework por meio
de três principais recursos:
1.​ Autoconfiguração: os aplicativos são inicializados com dependências
predefinidas e não é necessário configurá-las manualmente. Como o Java
Spring Boot é oferecido com recursos integrados de autoconfiguração, ele
configura automaticamente o Spring Framework subjacente e soluções de
terceiros com base em suas definições (e com base nas práticas
recomendadas, o que ajuda a evitar erros).

2.​ Abordagem opinativa à configuração: inclui e configura dependências de

iniciador, com base nas necessidades do seu projeto. Após avaliar a
estrutura, o Spring Boot escolhe quais pacotes instalar e quais valores
padrão usar.
É possível definir as necessidades do seu projeto durante o processo de
inicialização, durante o qual é possível escolher entre diversas dependências
de iniciador, chamadas de Spring Starters, que abrangem os casos de uso
mais comuns. É aí que entra o Spring Boot Initializr que iremos utilizar na
próxima sessão.
Exemplos de starters (iniciadores) mais utilizados:
Spring Web: permite criar aplicativos da web baseados em Spring
com configuração mínima incluindo todas as dependências
necessárias ao seu projeto, como o servidor da web Apache Tomcat.
Spring Security: adiciona automaticamente recursos de autenticação
e controle de acesso aos seus aplicativos.

O Spring Boot inclui mais de 50 Spring Starters, e há muitos outros

iniciadores disponíveis de terceiros.

3.​ A capacidade de criar aplicativos independentes: O Spring Boot ajuda os

desenvolvedores a criar aplicativos que são executados com autonomia.
Especificamente, essa ferramenta permite criar aplicativos independentes
que podem ser executados de maneira autônoma e que não dependem de
um servidor da web externo, devido à integração de um servidor da web,
como o Tomcat ou o Netty, ao seu aplicativo durante o processo de
inicialização. Como resultado, você pode iniciar seu aplicativo em qualquer
plataforma simplesmente pressionando o comando Executar.
 2.1.​ Criando um projeto Spring Boot

Criaremos um projeto para transformar nosso ZAcademico em um sistema Web.

Assim, iremos reaproveitar o código que já fizemos anteriormente, porém em um
novo projeto.

Vamos utilizar o Spring Initializr para criar nosso primeiro projeto Spring Boot.
Acesse https://start.spring.io/

Em Project deixar o Maven. Em Language, deixar Java.

Em Spring Boot deixar a versão mais recente sem ser a SNAPSHOT.
Em Project Metadata:
Group: br.ifpe.jaboatao
Artifact: zacademicoweb
Descrição: Sistema Zacademico Web
Packaging: Jar
Java: a mesma versão que estiver instalada em seu computador

Do lado direito pesquisaremos pelas seguintes dependências:

Clique no botão Generate, que fica no final da página. Salve o arquivo compactado
e o extraia.
Abra a pasta com os arquivos no Visual Studio Code (ou qualquer outra IDE de sua
preferência).
Esta é a estrutura do nosso projeto

Dentro da pasta src temos as pastas main e test. Iremos trabalhar na pasta main, a
qual contém outras duas pastas:
●​ java: que conterá todos os arquivos .java

●​ resources: esta pasta só existe porque inserimos a dependência chamada

Thymeleaf que é uma engine de template. Nela ficarão contidos os arquivos
de template,os arquivos html e o arquivo application.properties, que
utilizaremos no decorrer do projeto.

Trabalharemos nestas pastas seguindo o padrão de projetos

Model-View-Controller (MVC).

2.1.1.​ Padrão de Projetos MVC

O padrão de projeto Model-View-Controller (MVC) é um dos mais conhecidos
e utilizados no desenvolvimento de software, especialmente em sistemas interativos
e aplicações web. Ele é um padrão arquitetural que visa organizar o código de
forma mais modular, separando as responsabilidades em três componentes
distintos: Model, View e Controller.

1. Model (Modelo)
O Model é responsável pela lógica de negócio e pelos dados da aplicação. Ele
representa o estado da aplicação e é a camada que interage com o banco de dados
ou outras fontes de dados. Ele também pode realizar cálculos, validações e outras
operações necessárias para manipular os dados da aplicação. O Model não sabe
nada sobre a interface do usuário ou sobre como os dados são apresentados.

No nosso ZAcademico, os modelos são as classes que representam o aluno, o

professor e o técnico administrativo (ou seja, os usuários), cada um com seus
atributos e métodos. Também poderíamos ter métodos para adicionar, remover ou
atualizar estes usuários no banco de dados (estes métodos na verdade, ficarão em
outras classes específicas para manipulação de banco de dados, mas que também
são classes de modelo). Aqui iremos reaproveitar o que já fizemos.

2. View (Visão)
A View é a camada responsável pela apresentação dos dados ao usuário. Ela
mostra a interface gráfica e interage com o usuário, mas não contém lógica de
negócio. A View observa as mudanças no Model e atualiza a exibição para refletir
essas mudanças. Ela está mais focada em como os dados serão apresentados ao
usuário.
No nosso sistema, a View será responsabilidade da pasta resources, pois é nela
que estão os templates e arquivos html estáticos que irão exibir os dados em
formato web. Teremos aqui os formulários para inserir novos dados, bem como os
de consulta e de resultado de consultas.

3. Controller (Controlador)
O Controller atua como intermediário entre o Model e a View. Ele recebe as
entradas do usuário a partir da View (como cliques, teclas pressionadas, etc.) e
decide o que fazer com essas entradas, geralmente manipulando o Model ou
alterando a exibição da View. O Controller pode modificar o Model, o que pode
resultar em uma atualização na View.
No ZAcademico, as classes de Controller conterão as rotas para onde os dados de
inserção, de consulta ou de update vão ser enviados pelos formulários e links e
tratados nas classes modelo.

Exemplo de Fluxo de interação no MVC no nosso sistema:

 1.​ O usuário interage com a View.
2.​ A View envia a solicitação ao Controller.
3.​ O Controller processa a solicitação e interage com o Model.
4.​ O Model altera seu estado, se necessário, e notifica a View sobre a mudança.
5.​ A View é atualizada para refletir os dados mais recentes do Model.

Benefícios do MVC:
●​ Separation of Concerns (Separação de Responsabilidades): O padrão
permite separar claramente as responsabilidades de cada parte do sistema, o
que torna o código mais organizado, modular e fácil de manter.
●​ Facilidade de manutenção: Mudanças na interface do usuário (View)
podem ser feitas sem afetar a lógica de negócios (Model) e vice-versa.
●​ Testabilidade: A separação facilita a realização de testes unitários, pois as
funcionalidades estão bem divididas em componentes independentes.
●​ Escalabilidade: Como cada parte da aplicação pode ser alterada
independentemente, o sistema pode ser mais facilmente escalado ou
expandido no futuro.

Em resumo, o padrão MVC ajuda a estruturar a aplicação de forma que a interação

entre a interface do usuário, a lógica de negócios e os dados seja clara e eficiente,
facilitando a manutenção e a evolução do sistema.
 2.1.2.​ Criando o Model
​ Vamos criar dentro da pasta main uma pasta chamada models. Como já temos
algumas classes de modelo prontos das aulas anteriores (Usuario.java, Aluno.java,
Professor.java, NotaSelecao.java, etc.), vamos apenas copiar estas classes para a pasta
models.
​ Agora vamos criar dentro da pasta main a pasta dao, onde ficarão as classes de
modelo de persistência de dados, ou seja, aquelas que inserem novos registros de
entidades no banco de dados.

2.1.2.1.​ Data Access Object (DAO)

O DAO é um padrão que se concentra em fornecer uma abstração para a persistência de
dados. Ele atua diretamente sobre o armazenamento, como um banco de dados, e fornece
métodos para realizar operações como salvar, atualizar, excluir e recuperar objetos de
forma isolada. O DAO tende a ser mais específico em relação a uma única entidade ou
tabela do banco de dados.

Quando usar DAO:

●​ Quando o foco principal é em operações CRUD (Create, Read, Update, Delete)

sobre uma única entidade ou um conjunto muito restrito de dados. Ex: cadastrar um
Aluno, Professor, Técnico Administrativo.
●​ Quando a complexidade do acesso a dados é relativamente simples e não envolve
múltiplas fontes ou camadas.
●​ Quando você deseja abstrair a lógica de persistência e interação com o banco de
dados de uma maneira mais direta e explícita, sem a necessidade de se preocupar
com a lógica de negócios por trás.
●​
Exemplo 2: Um DAO pode ser usado para gerenciar a persistência de dados de um
Usuário. Ele forneceria métodos como:
getUserById(id)
saveUser(user)
deleteUser(id)
Aqui, cada método está diretamente relacionado a uma operação simples sobre os dados
de um único tipo de entidade.
—-----------------------------------------------------------------------------------------------------------------

Agora vamos criar na pasta dao a classe AlunoDAO.

Para realizar acesso ao banco de dados utilizaremos o JDBC, e para isso deveremos
adicionar a seguinte importação ao arquivo:

import org.springframework.jdbc.core.simple.JdbcClient;
Agora acrescente as demais linhas:

@Repository
public class AlunoDAO {

private final JdbcClient jdbcClient;

public AlunoDAO(JdbcClient jdbcClient){

this.jdbcClient = jdbcClient;
}
}

Iremos construir as operações de CRUD após o construtor.

2.1.3.​ Criando a View

Vamos criar o primeiro arquivo de visualização, que será o formulário de cadastro de
Aluno.

Crie o arquivo cadAluno.html na pasta templates que deve ser criada.

Sobre o Thymeleaf https://www.thymeleaf.org/doc/tutorials/3.1/usingthymeleaf.html

2.1.4.​ Criando o Controller

Para ser possível a comunicação dos dados da View para o Model e vice e versa,
temos que criar a camada controladora que ficará entre elas.

Crie uma na pasta java do projeto uma pasta chamada spring_boot (tem que ser
com esse nome mesmo, e deve ficar no mesmo nível da pasta model. Veja imagem
a seguir).
Dentro da pasta spring_boot crie uma classe chamada AlunoController.

Para indicar que essa classe é um controlador, vamos utilizar a anotação

@Controller logo acima da declaração da classe, como está a seguir:

@Controller
public class AlunoController {
…..

O Spring fornece um modelo de programação baseado em anotações. Os

componentes @Controller e @RestController usam anotações para expressar
mapeamentos de requisições (URLs), entradas de requisições (métodos -POST,
GET, etc. e dados de entrada), tratamento de exceções e muito mais. Ou seja,
utilizando a anotação @Controller indicamos à aplicação que esta classe fará a
recepção de requisições e de dados vindos da view.

Para o Controller enxergar o Model iremos chamar para essa classe uma classe de
modelo. No caso, chamaremos a classe AlunoDAO, pois queremos que os dados
sejam manipulados em banco de dados.

@Controller
public class AlunoController {
private final AlunoDAO alunoDAO;
public AlunoController(AlunoDAO alunoDAO){
this.alunoDAO = alunoDAO;
}

Após o construtor de AlunoController criaremos os métodos que receberão os

dados vindo das páginas da View.
Neste momento, criaremos um método para receber os dados que foram
inseridos no formulário de cadastro de aluno e que serão inseridos na tabela aluno.
Vamos chamar o método de cadastraAluno que terá como parâmetros um dado do
tipo Aluno anotado com @ModelAttribute e outro parâmetro do tipo Model. Este
método, por ser um dos que receberá dados vindos da View deverá ser anotado
com algum tipo de anotação de mapeamento de requisição que pode ser
@RequestMapping, @GetMapping, @PostMapping, @PutMapping,
@DeleteMapping ou @PatchMapping. Os mais utilizados são
@RequestMapping, @GetMapping e @PostMapping. Ver o seguinte link com
detalhes sobre Mapeamento de requisições
Spring(https://docs.spring.io/spring-framework/reference/web/we
bmvc/mvc-controller/ann-requestmapping.html)

O @RequestMapping tem como parâmetro obrigatório o value que deverá

receber a url de onde de destino da requisição (por exemplo, o action do formulário).
O segundo parâmetro é o method, que não é obrigatório, recebe o tipo de método
da requisição (GET, POST, PUT,etc.). Quando este segundo parâmetro não é
fornecido, considera-se que é o tipo GET.
Como nosso formulário teve como action a url “/cadaluno” e o método foi o
POST, nosso mapeamento será

@RequestMapping(value="/cadaluno",method=RequestMethod.POST)

O mapeamento acima pode ser substituído pela anotação @PostMapping,

onde já se é indicado que o método é do tipo POST e temos apenas que fornecer a
URL. Assim, no lugar do @RequestMapping podemos utilizar

@PostMapping(value="/cadaluno")

Caso o método de requisição fosse GET, poderíamos substituir o

@RequestMapping por @GetMapping(value="/cadaluno")
A anotação @ModelAttribute está no pacote
org.springframework.web.bind.annotation.ModelAttribute. Já a
classe Model está no pacote import org.springframework.ui.Model.
@ModelAttribute é uma anotação que recupera (pega) os parâmetros que
estão vindo da requisição HTTP (ou seja, da URL ou formulário que enviou os
dados). Já a classe Model cria um modelo que será enviado de volta à View.
​ Nosso método cadastraAluno tem como objetivo inserir um novo aluno na
tabela. Assim, iremos chamar o método create que criamos em alunoDAO,
passando o objeto aluno que está sendo recebido da requisição.
alunoDAO.create(aluno);

Se a transação de inserção ocorrer sem problemas podemos retornar algo para a

view utilizando o método addAttribute da classe Model
model.addAttribute("aluno", aluno);

O retorno de cadastraAluno será uma String que conterá o nome do arquivo html
que receberá a resposta. Digamos que o arquivo de resposta se chamará
resultCadAluno.html, então o retorno do método será

return "resultCadAluno";
O método completo ficaria como segue
@RequestMapping(value="/cadaluno", method=RequestMethod.POST)
public String cadastraAluno(@ModelAttribute Aluno aluno, Model
model) {
alunoDAO.create(aluno);

model.addAttribute("aluno", aluno);
return "resultCadAluno";
}

Com isso já temos o C do CRUD. Resta agora implementar as demais.

Para saber mais sobre anotações do Spring clique no link a seguir:

https://docs.spring.io/spring-framework/reference/testing/annotations/integration-stan
dard.html
https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-controller.html#p
age-title

A seguir está o link do livro Spring Boot: Acelere o desenvolvimento de

microsserviços, que está disponível na Biblioteca Online Pearson
https://plataforma.bvirtual.com.br/Leitor/Publicacao/213000/epub/7?code=GehkM6ul
Wu3Y08o6Gx2f3fPw+dnsPCrbR6O7Uj66lCZYp9K5RdsPwPXwbboll2lFvrFXHurYBe
K7j9No65r7Yw==
Também há o livro Vire o jogo com Spring Framework
https://plataforma.bvirtual.com.br/Acervo/Publicacao/212889