Autor: Lucas Menezes
Curso: Análise e Desenvolvimento de Sistemas — UNIP
Projeto: TechService — PIM IV
Tempo estimado de leitura: aproximadamente 15 minutos
Este artigo apresenta um estudo de caso baseado no desenvolvimento do TechService, projeto desenvolvido no PIM IV do curso de Análise e Desenvolvimento de Sistemas da Universidade Paulista (UNIP). O objetivo é demonstrar como aplicações Web e Mobile podem compartilhar uma mesma API, utilizando autenticação JWT, banco de dados relacional e uma arquitetura desacoplada.
Ao longo do desenvolvimento foram utilizadas tecnologias como .NET 8, ASP.NET Core MVC, .NET MAUI, Entity Framework Core, MySQL e Swagger/OpenAPI. A proposta deste artigo é apresentar as principais decisões arquiteturais adotadas, os mecanismos de segurança utilizados e os aprendizados obtidos durante a integração entre os diferentes componentes da solução.
1. Introdução
O desenvolvimento de sistemas corporativos modernos frequentemente exige que diferentes tipos de aplicações acessem as mesmas informações.
Uma empresa pode possuir, por exemplo, uma aplicação Web utilizada pela equipe administrativa e, ao mesmo tempo, um aplicativo Mobile utilizado por profissionais que trabalham em campo.
Nesse cenário, permitir que cada aplicação acesse diretamente o banco de dados pode trazer dificuldades relacionadas à segurança, manutenção, integridade das informações e evolução do sistema.
Uma alteração realizada diretamente por uma aplicação pode não seguir as mesmas regras utilizadas por outra, criando inconsistências e aumentando a complexidade da solução.
Uma alternativa para esse problema é utilizar uma API como camada intermediária entre as aplicações clientes e o banco de dados.
Esse foi um dos principais conceitos aplicados durante o desenvolvimento do TechService.
O projeto é composto por uma aplicação administrativa desenvolvida em ASP.NET Core MVC, uma aplicação Mobile utilizando .NET MAUI, uma Web API em .NET 8 e um banco de dados relacional MySQL.
Cada componente possui uma responsabilidade específica, mas todos trabalham de maneira integrada.
2. Contexto do projeto TechService
O TechService foi desenvolvido para auxiliar no gerenciamento de Ordens de Serviço (OS).
Em um cenário tradicional de atendimento técnico existe uma separação entre as atividades administrativas e aquelas executadas pelos técnicos em campo.
A equipe administrativa precisa cadastrar clientes e técnicos, criar Ordens de Serviço, acompanhar atendimentos e consultar informações gerenciais.
Já o técnico precisa de uma interface simplificada e adequada para dispositivos móveis, permitindo visualizar os atendimentos atribuídos, consultar informações e atualizar o status das atividades.
Criar uma única aplicação para atender os dois cenários poderia resultar em uma interface mais complexa e pouco adequada para cada perfil de utilização.
Por isso, o projeto foi dividido em aplicações diferentes.
Mesmo existindo interfaces distintas, ambas utilizam a mesma API e trabalham com a mesma base de dados.
Essa decisão foi importante para manter as regras centralizadas e evitar duplicação de funcionalidades.
3. Arquitetura geral da solução
A arquitetura do TechService foi organizada em quatro componentes principais:
[ TechServiceWeb - ASP.NET Core MVC ]
|
|
v
[ TechServiceApi ]
|
v
[ MySQL ]
^
|
|
[ TechServiceMaui - .NET MAUI ]
O TechServiceWeb representa a aplicação administrativa.
O TechServiceMaui representa a aplicação utilizada pelos técnicos.
O TechServiceApi funciona como camada central de comunicação e processamento das regras.
O MySQL é responsável pela persistência dos dados.
A principal característica dessa arquitetura é que nem a aplicação Web nem o aplicativo Mobile acessam diretamente o banco.
Toda operação passa primeiro pela API.
4. Por que utilizar uma API centralizada?
Durante o desenvolvimento de aplicações que possuem diferentes interfaces, uma questão importante é definir onde as regras de negócio serão executadas.
Uma possibilidade seria implementar parte dessas regras na aplicação Web e outra parte no aplicativo Mobile.
Apesar de essa abordagem funcionar em projetos menores, ela pode gerar problemas conforme o sistema cresce.
Imagine uma regra relacionada aos possíveis status de uma Ordem de Serviço.
Caso essa regra estivesse implementada separadamente nas duas aplicações, qualquer modificação futura teria que ser feita nos dois projetos.
Isso aumentaria a chance de inconsistências.
Ao centralizar essas regras na API, o fluxo fica diferente:
Aplicação
|
v
Requisição HTTP
|
v
TechServiceApi
|
v
Validação
|
v
Banco de Dados
A aplicação solicita determinada operação, mas é a API que realiza as validações necessárias antes de alterar os dados.
Dessa forma, independentemente de a requisição ter partido da aplicação Web ou do aplicativo Mobile, as mesmas regras são aplicadas.
Outro benefício é a possibilidade de adicionar novos sistemas no futuro.
Caso seja necessário criar uma nova aplicação, integração externa ou outro tipo de interface, ela também poderá utilizar a API já existente.
5. Desenvolvimento da API com .NET 8
A API representa o núcleo da arquitetura do TechService.
Ela foi desenvolvida utilizando .NET 8 e segue princípios utilizados em APIs REST.
Uma API REST disponibiliza recursos através de endereços HTTP conhecidos como endpoints.
Alguns exemplos simplificados seriam:
GET /api/clientes
GET /api/tecnicos
GET /api/ordens
POST /api/ordens
PUT /api/ordens/{id}
Cada método HTTP possui uma finalidade.
O GET é utilizado principalmente para consulta de dados.
O POST é utilizado para criação de novos recursos.
O PUT pode ser utilizado para alteração de recursos existentes.
Já o DELETE, quando necessário, permite representar operações de exclusão.
Esse padrão facilita a organização da API e torna sua utilização mais previsível por outras aplicações.
6. Comunicação utilizando JSON
Para que aplicações desenvolvidas com tecnologias diferentes consigam trocar informações, é necessário utilizar um formato comum.
No TechService, a comunicação com a API é realizada utilizando JSON.
Uma representação simplificada de uma Ordem de Serviço poderia ser:
{
"id": 125,
"cliente": "Empresa Exemplo",
"tecnico": "Carlos Silva",
"descricao": "Verificação de equipamento",
"status": "Em Atendimento"
}
O JSON possui uma estrutura simples, legível e amplamente utilizada em APIs.
A aplicação Web não precisa conhecer diretamente a estrutura física das tabelas existentes no MySQL.
Ela precisa conhecer apenas os dados que a API disponibiliza.
O mesmo princípio é aplicado ao aplicativo Mobile.
Essa separação reduz o nível de dependência entre a interface e o banco de dados.
7. Utilização de DTOs
Durante o desenvolvimento de APIs, nem sempre é adequado retornar diretamente todas as informações armazenadas nas entidades internas da aplicação.
Para isso podem ser utilizados DTOs — Data Transfer Objects.
Um DTO representa apenas os dados necessários para uma determinada operação.
Imagine uma entidade de usuário que possua informações relacionadas à autenticação e ao funcionamento interno da aplicação.
Nem todas essas informações devem ser retornadas quando o sistema simplesmente solicita uma listagem de usuários.
Um DTO pode, por exemplo, disponibilizar apenas:
Id
Nome
E-mail
Perfil
Isso melhora a organização da aplicação e evita a exposição desnecessária de dados.
Também facilita futuras alterações internas, pois o formato utilizado pela API pode permanecer estável mesmo que a implementação do banco sofra modificações.
8. Autenticação utilizando JWT
Como o TechService trabalha com informações administrativas e operacionais, determinados endpoints precisam ser protegidos.
Para isso foi utilizado o padrão JWT — JSON Web Token.
O processo começa quando o usuário informa suas credenciais.
De maneira simplificada:
Usuário
|
| Login e senha
v
TechServiceApi
|
| Validação
v
Banco de Dados
Caso as credenciais sejam válidas, a API gera um token JWT.
Esse token é devolvido para a aplicação.
Nas próximas requisições, a aplicação envia o token juntamente com a solicitação.
Aplicação
|
| Requisição + JWT
v
TechServiceApi
|
| Token válido?
v
Endpoint protegido
Isso permite proteger recursos que não devem estar disponíveis para usuários não autenticados.
9. Autenticação e autorização
Autenticação e autorização são conceitos relacionados, porém possuem responsabilidades diferentes.
A autenticação responde à pergunta:
Quem é este usuário?
Já a autorização responde:
O que este usuário está autorizado a fazer?
No TechService, um técnico autenticado pode utilizar funções relacionadas ao seu atendimento.
Já um usuário administrativo pode possuir acesso a funcionalidades de gerenciamento.
Essa separação é importante porque estar autenticado não deve significar possuir acesso irrestrito a todas as funções do sistema.
10. Persistência com Entity Framework Core
Para realizar a comunicação entre a API e o banco de dados foi utilizado o Entity Framework Core.
O Entity Framework funciona como uma camada de mapeamento entre objetos existentes na aplicação e registros existentes no banco.
Uma entidade relacionada a uma Ordem de Serviço poderia possuir propriedades como:
Id
ClienteId
TecnicoId
Descricao
Status
DataCriacao
Através do Entity Framework, essas estruturas podem ser manipuladas pelo código C#.
Isso reduz a necessidade de escrever consultas SQL manualmente para todas as operações.
O uso de um ORM não elimina a necessidade de entender SQL e modelagem relacional, porém facilita a comunicação entre o código da aplicação e o banco.
11. Modelagem relacional no MySQL
O banco de dados do TechService foi criado utilizando MySQL.
A base foi estruturada para representar as principais informações utilizadas pelo sistema, como usuários, técnicos, clientes, Ordens de Serviço, itens de serviço e histórico das alterações.
Um exemplo simplificado de relacionamento seria:
CLIENTES
|
| 1
|
| N
ORDENS_SERVICO
|
| N
|
| 1
TECNICOS
Uma Ordem de Serviço está associada a um cliente e pode ser atribuída a um técnico.
Em vez de armazenar repetidamente todas as informações de clientes e técnicos em cada Ordem de Serviço, são utilizados relacionamentos entre as tabelas.
Isso reduz duplicidade e melhora a organização das informações.
12. Integridade referencial
O banco de dados não deve funcionar apenas como um local para armazenar registros.
Ele também possui um papel importante na manutenção da consistência das informações.
Imagine que determinada Ordem de Serviço esteja relacionada a um cliente.
Se o sistema permitisse excluir esse cliente sem considerar as Ordens relacionadas, poderiam surgir registros inconsistentes.
Por isso, relacionamentos e restrições de integridade referencial são importantes.
Essa preocupação se torna ainda maior quando diferentes aplicações utilizam o mesmo conjunto de dados.
13. Histórico das Ordens de Serviço
Em um sistema de atendimento técnico, saber apenas o status atual de uma Ordem de Serviço pode não ser suficiente.
Também pode ser necessário acompanhar sua evolução.
Um fluxo de atendimento poderia ser:
Aberta
↓
Atribuída
↓
Em Atendimento
↓
Concluída
Por esse motivo, o TechService mantém informações relacionadas ao histórico das alterações.
Esse histórico ajuda no acompanhamento do atendimento e também pode ser utilizado para fins de auditoria.
14. Utilização de Triggers
Um dos recursos utilizados no banco de dados foi o uso de Triggers.
Triggers são ações executadas automaticamente pelo banco quando determinados eventos acontecem.
No TechService, uma Trigger pode ser utilizada para registrar alterações relacionadas ao status de uma Ordem de Serviço.
O funcionamento pode ser representado da seguinte maneira:
Atualização da OS
|
v
Mudança de Status
|
v
Trigger
|
v
Registro no Histórico
Uma vantagem dessa abordagem é que o histórico fica associado à alteração ocorrida no banco.
Independentemente de a modificação ter sido iniciada pelo sistema Web ou pelo aplicativo Mobile, o registro pode ser realizado de forma centralizada.
15. Stored Procedures
Outro recurso relacionado ao banco de dados é a utilização de Stored Procedures.
Uma Stored Procedure permite armazenar conjuntos de comandos SQL no próprio banco e executá-los quando necessário.
Esse recurso pode ser útil em operações específicas ou consultas que exigem maior processamento.
Entretanto, também é importante equilibrar as responsabilidades da aplicação e do banco.
Nem toda regra precisa estar armazenada dentro do SGBD.
Parte do trabalho de arquitetura consiste justamente em definir em qual camada cada responsabilidade deve permanecer.
16. Aplicação administrativa com ASP.NET Core MVC
A aplicação Web foi desenvolvida utilizando ASP.NET Core MVC.
O padrão MVC divide a aplicação em três conceitos principais: Model, View e Controller.
O Model representa os dados e estruturas utilizadas pelo sistema.
A View representa aquilo que será apresentado ao usuário.
O Controller recebe ações realizadas pelo usuário e coordena o fluxo da aplicação.
No TechService, essa aplicação possui foco administrativo.
Ela permite realizar operações relacionadas a clientes, técnicos, Ordens de Serviço e acompanhamento dos atendimentos.
Entretanto, a aplicação Web não acessa diretamente o banco de dados.
Quando precisa consultar ou alterar informações, ela utiliza a API.
17. Fluxo de uma operação Web
Considere como exemplo a criação de uma nova Ordem de Serviço.
O usuário preenche as informações através da aplicação administrativa.
Depois disso, o fluxo pode ocorrer da seguinte forma:
Usuário
|
v
TechServiceWeb
|
| POST
v
TechServiceApi
|
| Validação
v
MySQL
Após o processamento, a API retorna uma resposta HTTP.
Caso o recurso tenha sido criado corretamente:
201 Created
Caso o usuário não possua autenticação válida:
401 Unauthorized
Se determinado recurso não for encontrado:
404 Not Found
Esse padrão facilita o tratamento das situações pela aplicação cliente.
18. Aplicação Mobile com .NET MAUI
O aplicativo destinado aos técnicos foi desenvolvido utilizando .NET MAUI.
O .NET MAUI permite desenvolver aplicações multiplataforma utilizando o ecossistema .NET.
No TechService, o aplicativo possui uma finalidade diferente do sistema administrativo.
O técnico não precisa acessar todas as funções disponíveis para o gestor.
Seu foco é o atendimento operacional.
Entre as funcionalidades estão autenticação, consulta das Ordens de Serviço, visualização de detalhes e atualização do status dos atendimentos.
Isso permite desenvolver uma interface mais adequada à utilização em dispositivos móveis.
19. Consumo da API pelo Mobile
Assim como o sistema Web, o aplicativo também utiliza requisições HTTP.
Após o login, o aplicativo recebe o token JWT.
Esse token passa a ser utilizado nas requisições protegidas.
Por exemplo:
TechServiceMaui
|
| GET /api/ordens
| Authorization: Bearer TOKEN
v
TechServiceApi
A API valida o token antes de devolver os dados.
Esse modelo evita a necessidade de enviar login e senha novamente em cada requisição.
20. Uma API para diferentes aplicações
Um dos principais benefícios observados durante o desenvolvimento foi a possibilidade de reutilizar a mesma camada de serviços.
De maneira simplificada:
WEB
|
+------> API ------> MySQL
|
MOBILE
Apesar de as interfaces serem diferentes, ambas trabalham com as mesmas regras e informações.
Uma Ordem de Serviço criada pelo sistema administrativo pode posteriormente aparecer no aplicativo utilizado pelo técnico.
Depois que o técnico atualiza o atendimento, essa mudança pode ser visualizada pelo gestor.
Esse comportamento é possível porque ambas as aplicações utilizam a mesma API.
21. Documentação com Swagger/OpenAPI
Durante o desenvolvimento de uma API é importante conseguir visualizar e testar os endpoints existentes.
Para isso foi utilizado Swagger/OpenAPI.
A ferramenta permite visualizar rotas como:
GET /api/clientes
POST /api/clientes
GET /api/tecnicos
POST /api/tecnicos
GET /api/ordens
POST /api/ordens
PUT /api/ordens/{id}
Além de atuar como documentação, o Swagger ajuda durante os testes.
É possível enviar requisições e verificar as respostas retornadas pela API.
Isso foi útil especialmente durante a integração com as aplicações Web e Mobile.
22. Importância dos códigos HTTP
Uma API precisa informar corretamente o resultado de uma operação.
Alguns dos principais códigos utilizados são:
200 OK indica que a requisição foi processada corretamente.
201 Created indica a criação de um novo recurso.
400 Bad Request pode indicar que os dados enviados são inválidos.
401 Unauthorized indica ausência de autenticação válida.
404 Not Found indica que o recurso solicitado não foi localizado.
500 Internal Server Error representa uma falha ocorrida durante o processamento no servidor.
O tratamento correto desses códigos melhora a comunicação entre API e aplicações clientes.
23. Segurança em uma arquitetura distribuída
Ao separar o sistema em diferentes componentes, a segurança passa a ter ainda mais importância.
A segurança não deve existir apenas na tela de login.
Ela precisa estar presente em diferentes partes da arquitetura.
No TechService, alguns dos principais cuidados são evitar o acesso direto ao banco pelas aplicações clientes, proteger endpoints, validar os dados recebidos, controlar permissões, evitar retorno desnecessário de informações sensíveis e utilizar mecanismos adequados de autenticação.
Em um ambiente produtivo, outros recursos também seriam importantes, como HTTPS, gerenciamento seguro de credenciais e monitoramento.
24. Benefícios do desacoplamento
Um dos principais conceitos observados durante o projeto foi o desacoplamento.
A aplicação Mobile não precisa saber como a aplicação Web foi desenvolvida.
Da mesma maneira, o sistema Web não precisa conhecer detalhes internos do aplicativo Mobile.
Ambos precisam apenas conhecer os contratos disponibilizados pela API.
Isso facilita manutenção e evolução.
Caso a interface Web seja modificada futuramente, a API pode continuar funcionando normalmente.
O mesmo vale para a aplicação Mobile.
Esse modelo também facilita a criação de novas aplicações no futuro.
25. Desafios encontrados durante o desenvolvimento
A integração entre diferentes tecnologias também apresenta dificuldades.
Um dos desafios é manter os modelos utilizados pelas aplicações compatíveis com aquilo que a API disponibiliza.
Uma alteração realizada em determinado DTO pode exigir mudanças nos clientes que utilizam esse endpoint.
Outro ponto importante é a autenticação.
Não basta simplesmente gerar um token JWT.
As aplicações precisam armazená-lo e enviá-lo corretamente nas requisições protegidas.
Também é necessário considerar falhas de comunicação.
Uma aplicação Mobile pode ser utilizada em uma conexão instável.
Por isso, uma requisição pode falhar e o sistema precisa estar preparado para tratar essa situação adequadamente.
26. Organização e manutenção do código
À medida que um sistema cresce, a organização do código passa a ter impacto direto na manutenção.
Separar responsabilidades ajuda a evitar que uma única classe concentre funções demais.
Controllers devem atuar principalmente no tratamento das requisições e encaminhamento das operações.
DTOs podem ser utilizados para organizar as informações enviadas e recebidas.
O acesso ao banco também deve seguir uma estrutura definida.
Essa preocupação é importante inclusive em projetos acadêmicos, pois permite aplicar conceitos próximos aos utilizados em projetos corporativos.
27. Possíveis evoluções do TechService
A arquitetura criada também possibilita futuras melhorias.
O sistema poderia receber funcionalidades como anexos nas Ordens de Serviço, fotografias dos atendimentos, geolocalização, indicadores de SLA, novos dashboards, notificações e relatórios.
Outra possibilidade seria realizar integração com sistemas externos.
Como existe uma API centralizada, novas aplicações podem consumir os recursos já disponíveis sem precisar acessar diretamente o banco.
Esse é um dos benefícios de projetar a arquitetura pensando não apenas no funcionamento atual, mas também em possíveis evoluções.
28. Computação em nuvem
Outro assunto abordado durante o PIM IV foi a utilização de infraestrutura em nuvem.
Uma solução como o TechService poderia ser hospedada em uma plataforma como o Google Cloud Platform (GCP).
Em um cenário de produção, recursos diferentes poderiam ser utilizados para executar aplicações, disponibilizar serviços, armazenar dados e realizar monitoramento.
Entretanto, é importante diferenciar arquitetura da aplicação de ambiente de hospedagem.
A arquitetura Web + API + Mobile + banco de dados não depende obrigatoriamente de uma infraestrutura em nuvem para funcionar.
A cloud representa uma possibilidade de implantação e evolução da solução.
29. Principais aprendizados
O desenvolvimento do TechService permitiu observar na prática como diferentes conceitos estudados durante o curso podem trabalhar em conjunto.
Entre os principais pontos aplicados estiveram API REST, comunicação JSON, autenticação JWT, Entity Framework Core, banco de dados relacional, ASP.NET Core MVC, .NET MAUI, Swagger, integridade dos dados e separação de responsabilidades.
Também foi possível compreender melhor a importância de manter as aplicações desacopladas.
ASP.NET Core MVC, .NET MAUI, Web API e MySQL possuem funções diferentes, mas conseguem trabalhar dentro da mesma solução.
A experiência de integrar essas tecnologias foi uma das partes mais relevantes do projeto.
30. Conclusão
O desenvolvimento de uma aplicação multiplataforma envolve mais do que simplesmente criar interfaces diferentes.
Também é necessário definir como essas aplicações irão compartilhar informações, onde as regras de negócio serão executadas e como os dados serão protegidos.
No TechService, a utilização de uma API REST desenvolvida em .NET 8 permitiu criar uma camada intermediária entre as aplicações Web e Mobile e o banco de dados MySQL.
A aplicação administrativa em ASP.NET Core MVC e o aplicativo desenvolvido com .NET MAUI possuem finalidades diferentes, porém utilizam a mesma camada de serviços.
A autenticação utilizando JWT auxilia na proteção dos endpoints, enquanto o Entity Framework Core realiza a integração entre a aplicação e o banco de dados.
Ferramentas como Swagger/OpenAPI também contribuíram para a documentação e realização de testes.
Além disso, recursos do banco de dados, como Triggers e Stored Procedures, foram utilizados para auxiliar no controle e na consistência das informações.
Durante o desenvolvimento, ficou evidente que uma arquitetura organizada facilita não apenas a implementação inicial, mas também a manutenção e a evolução futura do sistema.
Mais do que desenvolver aplicações independentes, o principal desafio do projeto foi fazer com que diferentes componentes trabalhassem de forma integrada.
O TechService serviu, portanto, como uma aplicação prática de diversos conceitos estudados ao longo do curso de Análise e Desenvolvimento de Sistemas, permitindo compreender melhor a relação entre desenvolvimento Web, desenvolvimento Mobile, APIs, segurança e bancos de dados.
Referências
MICROSOFT. .NET 8 Documentation. Microsoft Learn.
MICROSOFT. ASP.NET Core Web API Documentation. Microsoft Learn.
MICROSOFT. ASP.NET Core MVC Documentation. Microsoft Learn.
MICROSOFT. .NET MAUI Documentation. Microsoft Learn.
MICROSOFT. Entity Framework Core Documentation. Microsoft Learn.
MYSQL. MySQL Reference Manual.
OPENAPI INITIATIVE. OpenAPI Specification.
IETF. JSON Web Token (JWT) — RFC 7519.
Top comments (0)