| Spring Framework | |
|---|---|
| Desenvolvedor | VMware |
| Lançamento inicial | 1 de outubro de 2002 |
| Lançamento estável | |
| Repositório | |
| Escrito em | Java |
| Plataforma | Jakarta EE |
| Tipo | Framework de aplicação |
| Licença | Licença Apache 2.0 |
| Website | spring |
O Spring Framework é um framework de aplicação e um contêiner de inversão de controle para a plataforma Java. Os recursos principais do framework podem ser usados por qualquer aplicação Java, mas existem extensões para a criação de aplicações web sobre a plataforma Jakarta EE. O framework não impõe nenhum modelo de programação específico. O framework tornou-se popular na comunidade Java como um complemento ao modelo Enterprise JavaBeans (EJB). O Spring Framework é um software livre e de código aberto.:
| Versão | Data |
|---|---|
| 0.9 | 2003 |
| 1.0 | 24 de março de 2004 |
| 2.0 | 2006 |
| 3.0 | 2009 |
| 4.0 | 2013 |
| 5.0 | 2017 |
| 6.0 | 22 de novembro de 2022 |
| 6.1 | 16 de novembro de 2023 |
| 6.2 | 14 de novembro de 2024 |
| 7.0 | 13 de novembro de 2025 |
A primeira versão foi escrita por Rod Johnson, que lançou o framework juntamente com a publicação de seu livro Expert One-on-One J2EE Design and Development em outubro de 2002. O framework foi lançado pela primeira vez sob a licença Apache 2.0 em junho de 2003. O primeiro lançamento de produção, a versão 1.0, foi lançado em março de 2004. O Spring 1.2.6 ganhou um prêmio Jolt de produtividade e um JAX Innovation Award em 2006. Spring 2.0 foi lançado em outubro de 2006, Spring 2.5 em novembro de 2007, Spring 3.0 em dezembro de 2009, Spring 3.1 em dezembro de 2011 e Spring 3.2.5 em novembro de 2013. O Spring Framework 4.0 foi lançado em dezembro de 2013. Melhorias notáveis no Spring 4.0 incluíram suporte para Java SE 8, Groovy 2, alguns aspectos do Java EE 7 e WebSocket.
Spring Framework 4.2.0 foi lançado em 31 de julho de 2015 e imediatamente atualizado para a versão 4.2.1, lançada em 1º de setembro de 2015. Ele é "compatível com Java 6, 7 e 8, com foco em refinamentos principais e recursos modernos da web".
Spring Framework 4.3 foi lançado em 10 de junho de 2016 e foi suportado até 2020. Foi anunciado que seria "a última geração dentro dos requisitos gerais do sistema Spring 4 (Java 6+, Servlet 2.5+), [...]".
Spring 5 foi construído sobre o Reactor Core compatível com Reactive Streams.
Spring Framework 6.0 foi lançado em 16 de novembro de 2022 e veio com uma base Java 17+ e uma mudança para Jakarta EE 9+ (no espaço de nomes jakarta), com foco nas APIs Jakarta EE 10 recentemente lançadas, como Servlet 6.0 e JPA 3.1.
O Spring Framework inclui vários módulos que fornecem uma variedade de serviços:
BeanFactory e ApplicationContext). Neste contexto, spring-core é o artefato encontrado no módulo core pertencente ao grupo org.springframework. O artefato spring-core consiste no contêiner IoC, bem como nas classes utilitárias usadas em toda a aplicação.spring-aop é um artefato para o framework AOP.spring-jdbc é um artefato encontrado no módulo JDBC que suporta acesso JDBC incluindo classes de configuração de fonte de dados.spring-websocket.spring-oxm.Os módulos Spring são empacotados como arquivos JAR. Esses artefatos podem ser acessados via Maven Central Repository usando Maven ou Gradle.
O contêiner de inversão de controle (IoC) é o contêiner central do Spring Framework. Ele fornece um meio consistente de configurar e gerenciar objetos Java: usando reflexão. O contêiner é responsável por gerenciar os ciclos de vida dos objetos de objetos específicos:: criar esses objetos, chamar seus métodos de inicialização e configurar esses objetos conectando-os entre si.
Em muitos casos, não é necessário usar o contêiner ao usar outras partes do Spring Framework, embora seu uso torne a aplicação mais fácil de configurar e personalizar. O contêiner Spring fornece um mecanismo consistente para configurar aplicações: e se integra com quase todos os ambientes Java, desde aplicações de pequena escala até grandes aplicações empresariais.
O programador não cria diretamente um objeto, mas descreve como ele deve ser criado, definindo-o no arquivo de configuração do Spring. Da mesma forma, serviços e componentes não são chamados diretamente; em vez disso, um arquivo de configuração Spring define quais serviços e componentes devem ser chamados. Essa IoC visa aumentar a facilidade de manutenção e teste.
Objetos criados pelo contêiner são chamados de objetos gerenciados ou beans. O contêiner pode ser configurado carregando arquivos XML: ou detectando anotações Java específicas em classes de configuração. Essas fontes de dados contêm as definições de bean que fornecem as informações necessárias para criar os beans.
A anotação @Configuration é uma anotação específica do Spring que marca uma classe como a classe de configuração. A classe de configuração fornece os beans para o ApplicationContext do Spring. Cada um dos métodos na classe de configuração Spring é configurado com a anotação @Bean. A interface ApplicationContext então retornará os objetos configurados com a anotação @Bean como beans. A vantagem da configuração baseada em Java sobre a configuração baseada em XML é melhor segurança de tipo e refatorabilidade.
Existem vários tipos de inversão de controle. Injeção de dependência e busca de dependência são exemplos de inversão de controle. Objetos podem ser obtidos por meio de busca de dependência ou injeção de dependência.:
Injeção de dependência é um padrão onde o contêiner passa objetos: por nome para outros objetos, via construtores,: propriedades ou métodos de fábrica. Existem várias maneiras de implementar a injeção de dependência: injeção de dependência baseada em construtor, injeção de dependência baseada em setters e injeção de dependência baseada em campo.
Busca de dependência é um padrão onde um chamador pede ao objeto contêiner um objeto com um nome específico ou de um tipo específico.
O Spring Framework tem um recurso conhecido como autowiring, que usa o contêiner Spring para satisfazer automaticamente as dependências especificadas nas propriedades JavaBean para objetos do tipo apropriado na fábrica atual. Isso só pode ocorrer se houver apenas um objeto com o tipo apropriado.
Existem várias anotações que podem ser usadas para autowiring de POJOs, incluindo a anotação específica do Spring @Autowire (bem como várias outras anotações específicas do Spring que ajudam a resolver ambiguidade de autowiring, como as anotações @Qualifier ou @Primary), e as anotações Java padrão @Resource e @Inject.
A anotação @Qualifier pode ser usada em uma classe que define um bean para informar ao Spring que priorize a criação do bean ao fazer autowiring por nome.
A anotação @Primary pode ser usada em uma classe que define um bean para informar ao Spring que priorize a criação do bean ao fazer autowiring por tipo.
A anotação @Resource é uma anotação que está em conformidade com o JSR 250, ou Common Annotations for the Java Platform, e é usada para autowiring de referências a POJOs por nome.
A anotação @Inject é uma anotação que está em conformidade com o JSR 300, ou Standard Annotations for injection, e é usada para autowiring de referências a POJOs por tipo.
O Spring Framework tem seu próprio framework de programação orientada a aspectos (AOP) que modulariza preocupações transversais em aspectos. A motivação para criar um framework AOP separado é fornecer recursos básicos de AOP sem muita complexidade no design, implementação ou configuração. O framework Spring AOP aproveita ao máximo o contêiner Spring.
O framework Spring AOP é baseado no padrão proxy. Ele é configurado em tempo de execução. Isso elimina a necessidade de uma etapa de compilação ou tecelagem em tempo de carga. Por outro lado, a interceptação permite apenas a execução de métodos públicos em objetos existentes em um ponto de junção.
Comparado ao framework AspectJ, o Spring AOP é menos poderoso, mas também menos complicado. O Spring 1.2 inclui suporte para configurar aspectos AspectJ no contêiner. O Spring 2.0 adicionou mais integração com o AspectJ; por exemplo, a linguagem de ponto de corte é reutilizada e pode ser misturada com aspectos baseados em Spring AOP. Além disso, o Spring 2.0 adicionou uma biblioteca Spring Aspects que usa o AspectJ para oferecer recursos comuns do Spring, como gerenciamento de transações declarativo e injeção de dependência via tecelagem em tempo de compilação ou tempo de carga do AspectJ. A SpringSource usa o AOP do AspectJ em outros projetos Spring, como Spring Roo e Spring Insight, com o Spring Security oferecendo uma biblioteca de aspectos baseada em AspectJ.
O Spring AOP foi projetado para trabalhar com preocupações transversais dentro do Spring Framework.: Qualquer objeto que é criado e configurado pelo contêiner pode ser enriquecido usando Spring AOP.
Desde a versão 2.0 do framework, o Spring fornece duas abordagens para a configuração AOP:
@AspectJ.<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:mvc="http://www.springframework.org/schema/mvc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/mvc
http://www.springframework.org/schema/mvc/spring-mvc.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop.xsd">
A equipe do Spring decidiu não introduzir nova terminologia relacionada a AOP. Portanto, na documentação de referência do Spring e na API, termos como aspecto, ponto de junção, conselho, ponto de corte, introdução, objeto alvo (objeto aconselhado), proxy AOP e tecelagem têm todos os mesmos significados[carece de fontes] que na maioria dos outros frameworks AOP (particularmente o AspectJ).
O framework de acesso a dados do Spring aborda dificuldades comuns que os desenvolvedores enfrentam ao trabalhar com bancos de dados em aplicações. Suporte é fornecido para todos os frameworks de acesso a dados populares em Java: JDBC, iBatis/MyBatis, Hibernate, Java Data Objects (JDO, descontinuado desde 5.x), Jakarta Persistence API (JPA), Oracle TopLink, Apache OJB e Apache Cayenne, entre outros.
Para todos esses frameworks suportados, o Spring fornece estes recursos:
Todos esses recursos se tornam disponíveis ao usar classes modelo fornecidas pelo Spring para cada framework suportado. Críticos disseram que essas classes modelo são intrusivas e não oferecem vantagem sobre o uso (por exemplo) da API Hibernate diretamente. Em resposta, os desenvolvedores do Spring tornaram possível usar as APIs Hibernate e JPA diretamente. Isso, no entanto, requer gerenciamento de transações transparente, pois o código da aplicação não assume mais a responsabilidade de obter e fechar recursos do banco de dados, e não suporta tradução de exceções.
Juntamente com o gerenciamento de transações do Spring, seu framework de acesso a dados oferece uma abstração flexível para trabalhar com frameworks de acesso a dados. O Spring Framework não oferece uma API comum de acesso a dados; em vez disso, todo o poder das APIs suportadas é mantido intacto.[carece de fontes] O Spring Framework é o único framework disponível em Java que oferece ambientes de acesso a dados gerenciados fora de um servidor de aplicações ou contêiner.
Ao usar o Spring para gerenciamento de transações com Hibernate, os seguintes beans podem ter que ser configurados:
Datasource como com.mchange.v2.c3p0.ComboPooledDataSource ou org.apache.commons.dbcp.BasicDataSourceSessionFactory como org.springframework.orm.hibernate3.LocalSessionFactoryBean com um atributo DataSource:HibernateProperties: como org.springframework.beans.factory.config.PropertiesFactoryBeanTransactionManager como org.springframework.orm.hibernate3.HibernateTransactionManager com um atributo SessionFactoryOutros pontos de configuração incluem:
O framework de gerenciamento de transações do Spring traz um mecanismo de abstração para a plataforma Java. Sua abstração é capaz de:
Em comparação, a Java Transaction API (JTA) suporta apenas transações aninhadas e globais, e requer um servidor de aplicações (e em alguns casos, a implantação de aplicações em um servidor de aplicações).
O Spring Framework fornece um PlatformTransactionManager para várias estratégias de gerenciamento de transações:
JtaTransactionManager: e UserTransaction:Além deste mecanismo de abstração, o framework fornece duas maneiras de adicionar gerenciamento de transações a aplicações:
TransactionTemplate do Spring@Transactional, etc.)Juntamente com o framework de acesso a dados do Spring — que integra o framework de gerenciamento de transações — é possível configurar um sistema transacional através da configuração sem ter que depender de JTA ou EJB. O framework transacional também se integra a mecanismos de mensageria e cache.

O Spring Framework possui seu próprio framework web modelo–visão–controlador (MVC), que não foi originalmente planejado. Os desenvolvedores do Spring decidiram escrever seu próprio framework web como reação ao que perceberam como o design ruim do (então) popular framework web Jakarta Struts, bem como deficiências em outros frameworks disponíveis. Em particular, eles sentiram que havia separação insuficiente entre as camadas de apresentação e manipulação de requisições, e entre a camada de manipulação de requisições e o modelo.
Como o Struts, o Spring MVC é um framework baseado em requisições.: O framework define interfaces de estratégia: para todas as responsabilidades que devem ser tratadas por um framework moderno baseado em requisições. O objetivo de cada interface é ser simples e clara para que seja fácil para os usuários do Spring MVC escreverem suas próprias implementações, se assim desejarem. O MVC abre caminho para um código de front-end mais limpo. Todas as interfaces estão fortemente acopladas à API Servlet. Este forte acoplamento à API Servlet é visto por alguns como uma falha por parte dos desenvolvedores do Spring em oferecer um alto nível de abstração para aplicações baseadas na web. No entanto, este acoplamento garante que os recursos da API Servlet permaneçam disponíveis para os desenvolvedores, ao mesmo tempo que oferece um framework de alta abstração para facilitar o trabalho com ela.
A classe DispatcherServlet é o controlador frontal do framework e é responsável por delegar o controle às várias interfaces durante as fases de execução de uma requisição HTTP.
As interfaces mais importantes definidas pelo Spring MVC, e suas responsabilidades, estão listadas abaixo:
Controller: fica entre Model e View para gerenciar requisições recebidas e redirecionar para a resposta apropriada. Controller mapeará a requisição http para os métodos correspondentes. Atua como um portão que direciona a informação recebida. Ele alterna entre entrar em Model ou View.HandlerAdapter: responsável pela execução de objetos que tratam requisições recebidas.HandlerInterceptor: responsável por interceptar requisições recebidas. Comparável, mas não igual a filtros de Servlet: (o uso é opcional: e não controlado por DispatcherServlet).HandlerMapping: responsável por selecionar objetos que tratam requisições recebidas (handlers) com base em qualquer atributo ou condição interna ou externa a essas requisições.LocaleResolver: responsável por resolver e opcionalmente salvar a localidade de um usuário individual.MultipartResolver: facilita o trabalho com uploads de arquivos envolvendo requisições recebidas.View: responsável por retornar uma resposta ao cliente. O View não deve conter nenhuma lógica de negócios e deve apenas apresentar os dados encapsulados pelo Model. Algumas requisições podem ir diretamente para View sem passar pela parte Model; outras podem passar por todos os três.ViewResolver: responsável por selecionar uma View com base em um nome lógico para a View (o uso não é estritamente obrigatório:).Model: responsável por encapsular dados de negócios. O Model é exposto à visão pelo controlador.: (o uso não é estritamente obrigatório).Cada interface de estratégia acima tem uma responsabilidade importante no framework geral. As abstrações oferecidas por essas interfaces são poderosas, permitindo um conjunto de variações em suas implementações.: O Spring MVC fornece implementações de todas essas interfaces e oferece um conjunto de recursos sobre a API Servlet. No entanto, desenvolvedores e fornecedores são livres para escrever outras implementações. O Spring MVC usa a interface Map do Java como uma abstração orientada a dados para o Model onde as chaves são esperadas como valores String.[carece de fontes]
A facilidade de testar as implementações dessas interfaces é uma vantagem importante do alto nível de abstração oferecido pelo Spring MVC.: O DispatcherServlet está fortemente acoplado ao contêiner de inversão de controle do Spring para configurar as camadas web das aplicações. No entanto, aplicações web podem usar outras partes do Spring Framework, incluindo o contêiner, e optar por não usar o Spring MVC.
Quando um usuário clica em um link ou envia um formulário em seu navegador web, a requisição vai para o DispatcherServlet do Spring. O DispatcherServlet é um controlador frontal no Spring MVC. O DispatcherServlet é altamente personalizável e flexível. Especificamente, ele é capaz de lidar com mais tipos de handlers do que quaisquer implementações de org.springframework.web.servlet.mvc.Controller ou classes anotadas com org.springframework.stereotype.Controller. Ele consulta um ou mais mapeamentos de handlers. O DispatcherServlet escolhe um controlador apropriado e encaminha a requisição para ele. O Controller processa a requisição particular e gera um resultado. Isso é conhecido como Model. Esta informação precisa ser formatada em HTML ou qualquer tecnologia de front-end como Jakarta Server Pages (também conhecido como JSP) ou Thymeleaf. Esta é a View de uma aplicação. Toda a informação está no objeto Model e View. Quando o controlador não está acoplado a uma visão particular, o DispatcherServlet encontra a View real (como JSP) com a ajuda do ViewResolver.:
A partir da versão 3.0 da Especificação Servlet, existem algumas maneiras de configurar o DispatcherServlet:
web.xml como mostrado abaixo:<servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MyServlet</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
web-fragment.xml.javax.servlet.ServletContainerInitializer.org.springframework.web.WebApplicationInitializer.SpringBootServletInitializer.O framework de acesso remoto do Spring é uma abstração para trabalhar com várias tecnologias baseadas em RPC (chamada de procedimento remoto) disponíveis na plataforma Java, tanto para conectividade do cliente quanto para marshalling de objetos em servidores. O recurso mais importante oferecido por este framework é facilitar a configuração e o uso dessas tecnologias o máximo possível, combinando inversão de controle e AOP.
O framework fornece recuperação de falhas (reconexão automática após falha de conexão) e algumas otimizações para uso no lado do cliente de beans de sessão sem estado EJB remotos.
O Spring fornece suporte para estes protocolos e produtos prontos para uso:
O Apache CXF fornece integração com o Spring Framework para exportação de estilo RPC de objetos no lado do servidor.
Tanto a configuração do cliente quanto do servidor para todos os protocolos e produtos de estilo RPC suportados pelo framework de acesso remoto do Spring (exceto o suporte Apache Axis) são configuradas no contêiner principal do Spring.
Existe uma implementação alternativa de código aberto (Cluster4Spring) de um subsistema de remoção incluído no Spring Framework que visa suportar vários esquemas de remoção (1-1, 1-muitos, descoberta dinâmica de serviços).
A extensão Spring Boot é a solução de convenção sobre configuração do Spring para criar aplicações baseadas em Spring autônomas, de nível de produção, que você pode "apenas executar". Ela é pré-configurada com a "visão opinativa" da equipe Spring da melhor configuração e uso da plataforma Spring e bibliotecas de terceiros, para que você possa começar com o mínimo de complicação. A maioria das aplicações Spring Boot precisa de pouca configuração Spring.
Recursos principais:
Spring Roo é um projeto da comunidade que fornece uma abordagem alternativa, baseada em geração de código, para usar convenção sobre configuração para construir rapidamente aplicações em Java. Atualmente suporta Spring Framework, Spring Security e Spring Web Flow. O Roo difere de outros frameworks de desenvolvimento rápido de aplicações por focar em:
Spring Batch é um framework para processamento em lote que fornece funções reutilizáveis essenciais no processamento de grandes volumes de registros, incluindo:
Ele fornece serviços e recursos técnicos mais avançados que permitem jobs de lote de altíssimo volume e alto desempenho através de técnicas de otimização e particionamento.
O Spring Batch executa uma série de jobs; um job consiste em um número de etapas e cada etapa consiste em uma tarefa "READ-PROCESS-WRITE" ou uma tarefa de operação única (tasklet). Uma tarefa de "operação única" também é conhecida como tasklet. Isso significa fazer apenas uma única tarefa, como limpar os recursos antes ou depois de uma etapa ser iniciada ou concluída.
O processo "READ-PROCESS-WRITE" consiste nestas etapas: "ler" dados de um recurso (valores separados por vírgulas (CSV), XML ou banco de dados), "processá-los" e depois "escrevê-los" em outros recursos (CSV, XML ou banco de dados). Por exemplo, uma etapa pode ler dados de um arquivo CSV, processá-los e escrevê-los no banco de dados. O Spring Batch fornece várias classes para ler/escrever CSV, XML e banco de dados.
As etapas podem ser encadeadas para serem executadas como um job.
Spring Integration é um framework para integração de aplicações empresariais que fornece funções reutilizáveis essenciais para arquiteturas orientadas a mensagens ou eventos.
@ServiceActivator para declarar o componente que requer essa funcionalidade.SimpleMessagingGateway, fornece suporte essencial para gateways. SimpleMessagingGateway permite que a aplicação Spring especifique o canal que envia requisições e o canal que espera receber respostas. O foco principal do SimpleMessagingGateway é lidar com payloads, o que poupa o cliente dos detalhes intrincados das mensagens transmitidas e recebidas. SimpleMessagingGateway é usado junto com canais para permitir a integração com sistemas de arquivos, JMS, e-mail ou quaisquer outros sistemas que exijam payloads e canais.@Splitter para declarar o componente que requer essa funcionalidade.@Aggregator para declarar o componente que requer essa funcionalidade.O Spring Integration suporta arquiteturas baseadas em pipe-and-filter.
Uma regra essencial para lidar com fluxos de dados de forma eficaz é nunca bloquear. O WebSocket é uma solução viável para este problema. O Protocolo WebSocket é um protocolo de transporte de baixo nível que permite canais de comunicação full-duplex sobre uma conexão TCP. O WebSocket atua como uma alternativa ao HTTP para permitir comunicação bidirecional entre o cliente e o servidor. O WebSocket é especialmente útil para aplicações que exigem trocas frequentes e rápidas de pequenos pedaços de dados, em alta velocidade e volume.
O Spring suporta o protocolo WebSocket fornecendo a API WebSocket para a aplicação reativa. A anotação @EnableWebSocket fornece funcionalidade de processamento de requisição WebSocket quando colocada em uma classe de configuração Spring. Uma interface obrigatória é o WebSocketConfigurer, que concede acesso ao WebSocketConfigurer. Em seguida, a URL do WebSocket é mapeada para os handlers relevantes implementando o método registerWebSocketHandlers(WebSocketHandlerRegistry).
Spring WebFlux é um framework que segue o paradigma de programação funcional, projetado para construir aplicações Spring reativas. Este framework usa extensivamente programação funcional e Reactive Streams. Um bom caso de uso para Spring WebFlux é para aplicações que exigem o envio e recebimento de informações instantâneas, como uma aplicação web com capacidade de chat.
Embora aplicações que usam a tecnologia Spring WebFlux sejam geralmente menos legíveis do que suas contrapartes MVC, elas são mais resilientes e mais simples de estender. O Spring WebFlux reduz a necessidade de lidar com as complicações associadas à sincronização do acesso a threads.
O Spring WebFlux suporta server-sent events (SSE), que é uma tecnologia de push do servidor que permite ao cliente obter atualizações automáticas de um servidor através de uma conexão HTTP. Esta comunicação é unidirecional e compartilha várias semelhanças com o modelo publish/subscribe encontrado no JMS.
O contêiner pode se tornar um contêiner EJB (Enterprise JavaBeans) 3.0 parcialmente compatível por meio do projeto Pitchfork.[carece de fontes] Alguns[quem?] criticam o Spring Framework por não estar em conformidade com os padrões. No entanto, a SpringSource não vê a conformidade com EJB 3 como um objetivo principal e afirma que o Spring Framework e o contêiner permitem modelos de programação mais poderosos.
Uma vulnerabilidade de execução remota de código afetando certas versões do Spring Framework foi publicada em abril de 2022 sob CVE-2022-22965. Recebeu o nome de Spring4Shell em referência à recente vulnerabilidade Log4Shell, ambas tendo provas de conceito semelhantes nas quais os atacantes poderiam, em máquinas vulneráveis, obter acesso ao shell ou até mesmo controle total.