Prefácio
Como um codificador envolvido no desenvolvimento de Java, a importância da primavera é evidente. Você pode estar lidando com estruturas de primavera todos os dias. A primavera tem o nome, trazendo um conforto parecido com uma primavera para o desenvolvimento de aplicativos Java. Pode -se dizer que a primavera é uma base necessária para qualquer desenvolvedor de Java alcançar a tecnologia avançada. Obviamente, não é fácil aprender bem a primavera, especialmente para entender os princípios subjacentes da primavera. Leva muito tempo e energia para estudá -lo com cuidado, e constantemente tentativa e erro e resumir em projetos reais para formar seu próprio pensamento e compreensão. O blogueiro tinha um entendimento muito superficial da primavera no início, e foi possível confiar no problema que Du Niang poderia resolver de maneira geral ao encontrar problemas no projeto. No entanto, por mais de um ano desde que a primavera está em contato com a primavera, o entendimento de seu sistema de estrutura é bastante caótico, e a tecnologia profunda ainda é como um nevoeiro, e não formou sua própria cognição e compreensão, o que é muito desfavorável para a melhoria da tecnologia de programação. Em vista disso, decidi me acalmar e aprender a estrutura da primavera sistematicamente do começo ao fim, e registrar os detalhes de aprendizado e compartilhar o conhecimento técnico através da forma de um blog. Ok, vamos ao ponto
Introdução à estrutura principal da primavera
DI (injeção de dependência), injeção de dependência e outro conceito que costumamos ouvir sobre, na verdade, implementa as mesmas funções que o COI (inversão de controle), mas as mesmas funções são explicadas de diferentes perspectivas. O blogueiro aqui não vai analisar muito, há muitas explicações no Baidu. O que precisamos saber é o que é a injeção de dependência e por que a injeção de dependência é. Para entender esses dois pontos, acho que o aprendizado da primavera é o melhor em termos de pensamento.
Quando a primavera não é usada - ou seja, quando não há injeção de dependência, é difícil obter colaboração funcional mútua entre as classes de aplicações Java. Se uma determinada classe (a) precisar implementar suas funções, se precisar confiar na colaboração de outra classe (b), é necessário criar ativamente um objeto Classe B na Classe A para concluir as funções usando os métodos Classe B (você não deve se preocupar com métodos estáticos e outras situações aqui). Isso é equivalente a ser responsável pela Classe A pelo gerenciamento de todo o ciclo de vida dos objetos de classe B. Em casos extremamente simples, parece que não há problema para novos objetos de outra classe em uma classe, mas a relação colaborativa entre classes de aplicativos e classes complexas é frequentemente multilateral. Não sabemos quantos objetos alternativos a implementação de uma função de classe se baseará para cooperar. Portanto, a criação de objetos em uma classe e o gerenciamento de todo o ciclo de vida do objeto causará alto acoplamento de código e complexidade inimaginável. Então, imagine que, se pudermos entregar o ciclo de vida de um objeto a um componente de terceiros para a gerência e, quando uma classe precisar de outro objeto, o componente de terceiros será criado diretamente para ele. Dessa maneira, a classe só pode se concentrar na implementação de suas próprias funções sem gerenciar o ciclo de vida de outros objetos de classe, as funções dessa classe são muito mais simples. Sim, você deve ter entendido que a primavera é esse componente de terceiros. Só precisamos dizer à primavera (contêiner) quais objetos precisam ser gerenciados e não precisamos nos importar com a forma como a estrutura da primavera cria objetos. Dessa forma, quando uma determinada classe A requer objeto Classe B, se a classe B tiver sido declarada e entregue ao gerenciamento de contêineres da mola, quando o programa é executado para a Classe A e requer a Classe B, o contêiner da mola injeta objetos de classe B na injeção de classe A por meio de dependência para ajudar na conclusão de funções comerciais. Através da injeção de dependência de componentes de terceiros, os objetos não precisam mais criar e gerenciar dependências entre as próprias classes. Também existem muitas maneiras de criar injeção de dependência de objetos, como injeção de interface, injeção de método de construção, injeção de método de setter etc. Falando nisso, você deve ter uma compreensão relativamente direta da injeção de dependência. Quanto ao motivo pelo qual a injeção de dependência é necessária, o artigo acima já explicou com muita clareza. Para reduzir o acoplamento entre os componentes do código, devemos primeiro usar exemplos simples para experimentar intuitivamente os benefícios da injeção de dependência sobre o gerenciamento de objetos -
classe pública Man implementa Human {Private QQCar Car; public Man () {this.car = new QQCAR (); } @Override public void xiabibi () {} public void driveCar () {car.drive (); }}Existem duas implementações do carro da interface: Mercedes-Benz e QQ Car. Nos códigos acima do homem e no QQCAR, o driver veterano criou apenas objetos de carro QQ através do construtor, para que ele possa acionar apenas o carro QQ. Então, o que o motorista veterano deve fazer se quiser dirigir Mercedes-Benz? Você pede que ele recrie o objeto Mercedes-Benz? Esse código altamente acoplado parece estar impotente, por isso faremos algumas melhorias no código acima, injetando objetos:
classe pública Man implementa Human {Carro Privado; Public Man (carro do carro) {this.car = car; } @Override public void xiabibi () {} public void driveCar () {car.drive (); }}O código acima bloqueia objetos específicos com base em características polimórficas por meio da injeção de interface do construtor, para que os motoristas veteranos possam dirigir o que quiserem. Este é o benefício da injeção de dependência.
AOP (programação orientada para aspectos), programação orientada para o rosto. No desenvolvimento diário, quando concluímos uma certa função comercial, escrevemos muito código. Quando finalmente otimizamos o código, descobrimos que o código que realmente conclui a empresa pode ser apenas duas frases, e o restante não é muito relevante para esta parte do negócio. É completamente extraído apenas para implementar um determinado código de tecnologia. Então, naturalmente, o extraímos para uma classe de ferramentas, para que tudo o que você usa seja bom, apenas chamando o método da ferramenta. Vejamos um pouco mais. Além de concluir as funções de negócios relacionadas, os componentes funcionais de cada módulo de negócios envolvem operações adicionais, como logs, transações e controle de segurança. Essas não são as funções principais do módulo, mas são indispensáveis. Se essas funções extras forem adicionadas ao código, cada componente do sistema de negócios parecerá repetitivo demais e fará com que o código dos negócios pareça confuso e não o suficiente. Neste momento, você pergunta a Deus, seu código de negócios pode se concentrar apenas na implementação de negócios e ignorar coisas irrelevantes, como toras, transações etc.? Oh, Deus disse que estava tudo bem, então havia AOP. Se o objetivo da injeção de dependência é manter os componentes cooperativos em um estado de acoplamento relativamente solto, a AOP separa as funções espalhadas pelo aplicativo para formar componentes reutilizáveis. Nos termos leigos, logs, transações etc. são todos componentes reutilizáveis. Podemos extrair completamente os logs, transações, segurança e outros códigos funcionais espalhados em várias partes do código de negócios e nos tornar um componente de ferramenta separado. Declare -o como uma seção funcional na configuração da primavera e informe a Spring onde e quando você deseja usar (corte) esses componentes reutilizáveis. Esta é a minha simples interpretação da seção orientada para o rosto. Este artigo é apenas uma introdução, portanto o blogueiro explicará brevemente o conceito e não fará implementações específicas de código ou configuração. Ele será apresentado nas postagens subsequentes do blog. Bem -vindo a dar uma olhada.