Lo preferiría como registro, ya que hay menos repeticiones, pero ¿habría problemas?
IntelliJ sugiere que convierta una clase básica de Java @Service como esta:
@Service public class LocationService { private final PlaceRepository placeRepository; @Autowired public LocationService(PlaceRepository placeRepository) { this.placeRepository = placeRepository; } public List<PlaceDto> findPlacesByRegionId(Long regionId){ return placeRepository.findByRegionId(regionId).stream().map(place -> new PlaceDto(place.getId(), place.getName())).toList(); } }en un registro de Java @Service como este:
@Service public record LocationService(PlaceRepository placeRepository) { public List<PlaceDto> findPlacesByRegionId(Long regionId) { return placeRepository.findByRegionId(regionId).stream().map(place -> new PlaceDto(place.getId(), place.getName())).toList(); } }Permítanme citar al chico de Oracle :
JE 395 dice:
[Registros] son clases que actúan como portadores transparentes de datos inmutables.
Entonces, al crear un registro, le está diciendo al compilador, a sus colegas, al mundo entero, que este tipo se trata de datos. Más precisamente, datos que son (superficialmente) inmutables y accesibles de forma transparente. Esa es la semántica central: todo lo demás se deriva de aquí.
Si esta semántica no se aplica al tipo que desea crear, entonces no debe crear un registro. Si lo hace de todos modos (tal vez atraído por la promesa de no repetitivo o porque cree que los registros son equivalentes a @Data/@Value o clases de datos), está enturbiando su diseño y es muy probable que vuelva a morder usted. Así que no lo hagas.
UPD.
Pasé un par de minutos para descubrir cuál era la causa raíz de su declaración de que "IntelliJ sugiere que convierta una clase Java básica @Service como esta". Y encontré la siguiente discusión: https://youtrack.jetbrains.com/issue/IDEA-252036
De este modo:
Podría hacer eso, pero los registros tienen captadores (bueno, sin el prefijo get ). Qué capa de servicio no debería tener. Su Service Facade expone métodos públicos que también suelen ser @Transactional , no desea mezclarlos con métodos que nadie va a utilizar.
Además, los registros definen equals() y hashCode() que tampoco son necesarios para las clases de servicio.
Al final, el único tema común entre los Registros y los Servicios es que todos los campos suelen ser final y todos ellos suelen pasarse a través del constructor. Esto no tiene mucho en común. Así que parece una mala idea usar registros para esto.