Hoje conversei com meus colegas sobre se deveria usar uma combinação de @Configuration e @Bean para criar feijões no Spring Boot ou usar @Service e outras anotações diretamente na turma. O autor tende a usar o primeiro, ou seja, uma combinação de @Configuration e @Bean.
Vamos olhar um exemplo primeiro: o objetivo é criar um grão para o SearchService.
Use @Service diretamente:
Iniciar o aplicativo, acesso ao navegador: http://localhost:8081/search?q=koly, exibição da página: ["hello", "koly"]
Maneiras de usar @Configuration e @Bean:
Comparado ao uso direto de @Service código, existe uma classe AppConfig que remove as anotações @Service colocadas sobre o ElasticSearchServiceImpl. À primeira vista, há mais código e classes. Então, quais são os benefícios de usar o segundo?
O autor acredita que os benefícios são:
Separação das questões
Usando métodos @Configuration e @Bean, a criação dos grãos é toda em um só lugar, e a interface e sua implementação não têm nada a ver com a criação do grão.
Se a criação do bean precisar ser alterada, então você só precisa visualizar e modificar a classe de Configuração correspondente, e não precisa ir ao bean Java correspondente para fazer alterações. Por exemplo, às vezes a criação de beans precisa ser cooperada com @Scope ou @Profile, e só precisa modificar a classe Configuration.
Função única
@service anotação em si assume duas responsabilidades:
Uma é a criação de feijões;
A segunda é identificar uma classe como um serviço.
Indica que uma classe anotada é um "Serviço", originalmente definido por Domain-Driven
Design (Evans, 2003) como "uma operação oferecida como uma interface que permanece sozinha no modelo, sem estado encapsulado."
Acima está a explicação de Spring sobre @Service anotações. Esse is@Service na verdade representa uma operação de interface independente e sem estado no DDD.
Na forma de cooperação @Bean e @Configuration, a criação dos grãos é entregue a uma classe separada, e a identidade do Serviço é passada para a interface e o nome da classe em Java. Isso também se reflete em Spring Data, como Repository, que é identificado pelo nome, como CrudRepository. Portanto, o nome também é reconhecido pelo nome. Definições específicas de hierarquia podem ser usadas para fornecer mais camadas de acordo com o projeto pelo nome, sem depender das anotações fornecidas pelo Spring, como camada Mapper, camada Validator, etc.
Além disso, feijão e serviço são conceitos bidimensionais. Uma sobre a implementação concreta e outra sobre os conceitos em DDD.
Mais flexível
Usando @Bean métodos, você pode criar instâncias de classes na biblioteca. Se você usar o método @Service, não poderá adicionar @Service comentários às classes correspondentes na biblioteca.
Menos conhecimento
O princípio do conhecimento mínimo significa:
Quanto menos tecnologia ou conhecimento necessário para completar a função, melhor, garantindo assim a simplicidade do projeto e reduzindo a dificuldade de aprendê-lo.
Como não é possível criar instâncias de classes na biblioteca de classes usando @Service, você precisa usar a forma de @Configuration e @Bean ao encontrar necessidades semelhantes. Neste ponto, há anotações como @Service, @Configuration e @Bean em todo o projeto, e essas anotações fazem a mesma coisa, ou seja, criam o feijão.
Com @Service, há uma alta probabilidade de @Service, @Component, @Configuration e @Bean ao mesmo tempo.
Enquanto o uso de @Configuration e @Bean pode eliminar completamente o uso de @Service e @Component, o que está em linha com o princípio do conhecimento mínimo.
Por fim, aliás, os grãos Spring foram criados em XML e depois usaram Java para configuração. A principal razão para não usar XML é que ele não é conciso o suficiente e não possui recursos como verificação em tempo de compilação, em vez da necessidade de espalhar a criação de grãos entre classes.
Resumindo, o autor prefere usar métodos @Configuration e @Bean. |
Publicado em 30/08/2018 13:29:41
|
|
|
