[Java] Cuál de las dos os parece mejor

Kaledros

Iba a abrirlo en feda, pero mejor un hilo nuevo.

Vale, pregunta (que intento que sea seria). ¿Cuál de las dos opciones os parece mejor (más limpia, más escalable, más legible,etc) y por qué, pensando en que la cantidad de beans puede aumentar bastantecon el tiempo?

@Configuration
public class Configuration {

  MyService myService;
  MyService2 myService2;

  public Configuration(ApplicationContext context) {
    myService = context.getBean(MyService.class);
    myService2 = context.getBean(MyService2.class);
  }
  
//... } @Service public class MyService { String prop1; public MyService(Properties properties) { prop1 = properties.getProp1(); } } @Service public class MyService2 { String prop2; public MyService(Properties properties2) { prop2 = properties2.getProp2(); } }
@Configuration
public class Configuration {

  @Bean	
  MyService myService = new MyService(Properties properties);

  @Bean	
  MyService2 myService2 = new MyService2(Properties properties2);

}


public class MyService {
  String prop1;

  public MyService(Properties properties) {
    prop1 = properties.getProp1();
  }
}

public class MyService {
  String prop2;

  public MyService(Properties properties2) {
    prop2 = properties2.getProp2();
  }
}

Yo me decanto por la primera, pero quiero leer opiniones.

pantocreitor

La segunda la veo más limpia y legible. Si hablamos de escalabilidad al final en los 2 vas a tener un buen troncho por lo que igualmente me quedaría con la segunda.
También te digo que me gusta más usar las notaciones en caso de poder usarlas.

1 respuesta
B

.

1 respuesta
S

@Bean
MyService myService = new MyService(Properties properties);

En el segundo caso esto no es un error en la sintaxis?

De todas formas no es esto lo que necesitas?

@Autowired
MyService myService;

1 respuesta
Kaledros

#2 Pero en uno lo tienes todo dentro del constructor y en el otro tienes 400 variables que sólo sirven para invocar otros 400 constructores, que es algo que Spring te lo hace cómodamente.

#3 ¿A qué te refieres?

#4 Esa manera de hacerlo está desaconsejada en general, se considera mejor práctica hacerlo por constructor.

Konishi

Desde el desconocimiento, ¿no se puede hacer autowire y luego especificar en el constructor de la implementación lo que necesite?

1 1 respuesta
Postmortem

Me gusta más la primera, aunque no sé si es un tema de que lo he visto ahora en Quarkus o se puede también en Spring, el tema de pedir por constructor directamente MyService1 y MyService2 en lugar del application context

(y ya a eso le sumas con Lombok el @AllRequiredArgs o similar y te queda limpio y ready para tirarle unitarios, lo que me gusta de esta forma es que te permite mockear muy fácilmente los servicios)

1 respuesta
Kaledros

#7 Se pueden poner todos los beans como parámetros del constructor y Spring te los inyecta automáticamente, pero paso de tener un constructor con chorromil beans, meto el context y a correr.

#6 No te entiendo.

1 respuesta
Postmortem

#8 como digo, con lombok te ahorras tener que hacer el constructor, por lo que a mi forma de verlo tienes la elegancia del @Autowired pero siendo la "mejor práctica" a la vez, y con ciertas facilidades para testearlo.

Solo tendrías el constructor con muchos servicios a la hora de crearlo en un unitario, de todas formas yo nunca he visto un servicio que requiera más de 3 o 4 "inyecciones".

1 respuesta
Kaledros

#9 Vale, ya entiendo. En principio esto es una clase de configuración, hay varios componentes que se tienen que inyectar (properties, configuraciones, servicios, etc). Lo que pasa es que ahora se está haciendo a pelo con @Bean e invocando al constructor, que es mala práctica, y se debería hacer por constructor.

afhn

Bueno, si no usas ni lombok ni quieres configurar nada con spring, la segunda podría valerte al uso. Pero no sé, montar beans así siempre me ha parecido raro, teniendo librerías o paradigmas que automatizan esas cosas, es un poco ineficiente y arcaico.

1 respuesta
Kaledros

#11 Lo primero es como lo he hecho yo siempre.

Usuarios habituales