Comenzaré con un ejemplo simple. Tiene una aplicación de arranque Spring que ejecuta una clase CommandLineRunner en la inicialización.
// MyCommandLineRunner.java public class MyCommandLineRunner implements CommandLineRunner { private final Log logger = LogFactory.getLog(getClass()); @Autowired //IntelliJ Warning private DataSource ds; @Override public void run(String... args) throws Exception { logger.info("DataSource: " + ds.toString()); } } // Application.java @SpringBootApplication public class Application { public static void main(String... args) { SpringApplication.run(Application.class, args); } @Bean public MyCommandLineRunner schedulerRunner() { return new MyCommandLineRunner(); } } Ahora, así, esto funciona, todo está bien. Sin embargo, IntelliJ informa una advertencia donde se encuentra @Autowired (marqué dónde en el comentario)
El equipo de Spring recomienda: Utilice siempre la inyección de dependencia basada en constructores en sus beans. Utilice siempre aserciones para las dependencias obligatorias.
Ahora, si sigo esto, tengo una inyección de dependencia basada en constructor
@Autowired public MyCommandLineRunner(DataSource ds) { ... } Esto también significa que también tengo que editar Application.java , ya que el constructor necesita un argumento. En Application.java , si trato de usar la inyección de setter, recibiré la misma advertencia. Si refactorizo eso también, terminaré con un código, en mi opinión, desagradable.
// MyCommandLineRunner.java public class MyCommandLineRunner implements CommandLineRunner { private final Log logger = LogFactory.getLog(getClass()); private DataSource ds; @Autowired // Note that this line is practically useless now, since we're getting this value as a parameter from Application.java anyway. public MyCommandLineRunner(DataSource ds) { this.ds = ds; } @Override public void run(String... args) throws Exception { logger.info("DataSource: " + ds.toString()); } } // Application.java @SpringBootApplication public class Application { private DataSource ds; @Autowired public Application(DataSource ds) { this.ds = ds; } public static void main(String... args) { SpringApplication.run(Application.class, args); } @Bean public MyCommandLineRunner schedulerRunner() { return new MyCommandLineRunner(ds); } }El código anterior produce el mismo resultado, pero no informa ninguna advertencia en IntelliJ. Estoy confundido, ¿cómo es el segundo código mejor que el primero? ¿Estoy siguiendo una lógica incorrecta? ¿Debería estar cableado de manera diferente?
En resumen, ¿cuál es la forma correcta de hacer esto?
tenga en cuenta que DataSource es solo un ejemplo puro, esta pregunta se aplica a todo lo que se autoconecta.
nota 2 Solo para decir que MyCommandLineRunner.java no puede tener otro constructor vacío, ya que DataSource debe autoconectarse/inicializarse. Informará de un error y no se compilará.
Hay varias formas de mejorarlo.
Puede eliminar @Autowired de su MyCommandLineRunner mientras permite que un método @Bean construya una instancia de él. Inyecte el DataSource directamente en el método como argumento.
O elimine @Autowired y elimine el @Bean y coloque una anotación @Component en su MyCommandLineRunner para que lo detecte y elimine el método de fábrica.
Alinee su MyCommandLineRunner dentro de su método @Bean como una lambda.
MyCommandLineRunner public class MyCommandLineRunner implements CommandLineRunner { private final Log logger = LogFactory.getLog(getClass()); private final DataSource ds; public MyCommandLineRunner(DataSource ds) { this.ds = ds; } @Override public void run(String... args) throws Exception { logger.info("DataSource: " + ds.toString()); } }Y la clase de aplicación.
@SpringBootApplication public class Application { public static void main(String... args) { SpringApplication.run(Application.class, args); } @Bean public MyCommandLineRunner schedulerRunner(DataSource ds) { return new MyCommandLineRunner(ds); } }@Component @Component public class MyCommandLineRunner implements CommandLineRunner { private final Log logger = LogFactory.getLog(getClass()); private final DataSource ds; public MyCommandLineRunner(DataSource ds) { this.ds = ds; } @Override public void run(String... args) throws Exception { logger.info("DataSource: " + ds.toString()); } }Y la clase de aplicación.
@SpringBootApplication public class Application { public static void main(String... args) { SpringApplication.run(Application.class, args); } }CommandLineRunner en línea @SpringBootApplication public class Application { private static final Logger logger = LoggerFactory.getLogger(Application.class) public static void main(String... args) { SpringApplication.run(Application.class, args); } @Bean public MyCommandLineRunner schedulerRunner(DataSource ds) { return (args) -> (logger.info("DataSource: {}", ds); } }Todas estas son formas válidas de construir sus instancias. Cuál usar, usa el que te resulte más cómodo. Hay más opciones (todas las variaciones de las mencionadas aquí).
Considere hacer que el campo ds sea final, entonces no necesita @Autowired . Obtenga más información sobre la inyección de dependencias http://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-spring-beans-and-dependency-injection.html#using-boot-spring-beans -y-dependencia-inyección
Para mantener limpio el código, ¿ha considerado usar anotaciones de Lombok? @RequiredArgsConstructor(onConstructor = @__(@Autowired)) generaría el constructor con anotaciones @Autowired. Vea más aquí https://projectlombok.org/features/Constructor.html
Su código podría verse así:
@Slf4j @RequiredArgsConstructor // MyCommandLineRunner.java public class MyCommandLineRunner implements CommandLineRunner { //final fields are included in the constructor generated by Lombok private final DataSource ds; @Override public void run(String... args) throws Exception { log.info("DataSource: {} ", ds.toString()); } } // Application.java @SpringBootApplication @RequiredArgsConstructor(onConstructor_={@Autowired}) // from JDK 8 // @RequiredArgsConstructor(onConstructor = @__(@Autowired)) // up to JDK 7 public class Application { private final Datasource ds; public static void main(String... args) { SpringApplication.run(Application.class, args); } @Bean public MyCommandLineRunner schedulerRunner() { return new MyCommandLineRunner(ds); } }Edición posterior
La solución sin Lombok se basa en Spring para inyectar dependencia cuando se crea el bean
@SpringBootApplication public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } @Bean /** * dependency ds is injected by Spring */ public MyCommandLineRunner schedulerRunner(DataSource ds) { return new MyCommandLineRunner(ds); } } // MyCommandLineRunner.java public class MyCommandLineRunner implements CommandLineRunner { private final Log logger = LogFactory.getLog(getClass()); private final DataSource ds; public MyCommandLineRunner(DataSource ds){ this.ds = ds; } @Override public void run(String... args) throws Exception { logger.info("DataSource: "+ ds.toString()); } }