He estado experimentando con spring-data-rest (SDR) y estoy realmente impresionado con la rapidez con la que puedo crear una API de descanso. Mi aplicación se basa en el siguiente repositorio que me proporciona GET/archivos adjuntos y POST/archivos adjuntos
package com.deepskyblue.attachment.repository; import java.util.List; import org.springframework.data.repository.Repository; import com.deepskyblue.attachment.domain.Attachment; public interface AttachmentRepository extends Repository<Attachment, Long> { List<Attachment> findAll(); Attachment save(Attachment attachment); }Sin embargo, una cosa que me confunde es cómo agrego una lógica comercial personalizada. SDR parece genial si solo quiero una API de descanso para mis datos, sin embargo, una aplicación Spring tradicional normalmente tendría un nivel de servicio donde puedo tener lógica comercial. ¿Hay alguna forma de agregar esta lógica de negocios con SDR?
Hay muchas posibilidades.
Validadores ( http://docs.spring.io/spring-data/rest/docs/current/reference/html/#validation ) para validar objetos recibidos.
Controladores de eventos http://docs.spring.io/spring-data/rest/docs/current/reference/html/#events ) que se llamarán cuando la validación esté bien.
Controladores personalizados ( http://docs.spring.io/spring-data/rest/docs/current/reference/html/#customizing-sdr.overriding-sdr-response-handlers ) cuando desea manejar la solicitud manualmente.
Terminé creando un Aspecto personalizado que está relacionado con el método de repositorio. Algo como esto (maravilloso):
@Aspect @Component @Slf4j class AccountServiceAspect { @Around("execution(* com.test.accounts.account.repository.AccountRepository.save*(..))") Object saveAccount(ProceedingJoinPoint jp) throws Throwable { log.info("in aspect!") Object[] args = jp.getArgs() if (args.length <= 0 || !(args[0] instanceof Account)) return jp.proceed() Account account = args[0] as Account account.active = true jp.proceed(account) } }No es lo ideal, pero puede modificar el modelo antes de guardarlo sin escribir los controladores de descanso de datos de primavera desde cero.
Una buena respuesta en: https://www.reddit.com/r/java/comments/90wk5y/spring_rest_business_logic/
Si su servicio futuro puede tener alguna lógica comercial, incluso simple, no debe usar Spring Data Rest.
Spring Data Rest se adapta perfectamente al caso cuando solo necesita un control básico de las entidades (piense en CRUD).
Con el caso, uno podría comenzar con Spring Web, descansar los controladores y usar la representación JSON como sus vistas.
Los Events y el Validator pueden ayudar si su lógica trata con una sola entidad.
No me malinterpreten, en un proyecto normal puede encontrar muchos lugares en los que no hay una lógica pesada y Spring Data Rest se ajusta bien y puede ahorrar mucho tiempo.