Guía de Spring Data JPA

¿Qué es Spring Data JPA? Antes de comenzar Elección de una capa de acceso a datos de Java Instalación de Spring Data JPA Spring Repositories Repository Architectural Overv...

¿Qué es Spring Data JPA?

JPA de datos de primavera es parte de [Datos de primavera](http://projects. familia spring.io/spring-data).

Hablemos sobre qué es Spring Data JPA y algunas de las características que vamos a cubrir en este artículo. En primer lugar, este marco se basa en el popular y poderoso marco Spring y se considera uno de los proyectos centrales en el conjunto de herramientas de Spring.

Spring Data JPA también se basa y mejora JPA, que significa "API de persistencia de Java". La mayoría de las aplicaciones están respaldadas con algún tipo de almacén de datos. A medida que crezca la complejidad de su aplicación y el conjunto de características, encontrará que su capa de acceso a datos y el código de nivel de persistencia también crecerán.

Uno de los objetivos principales de Spring Data JPA es reducir su código y simplificar su capa de acceso a datos, manteniendo al mismo tiempo un conjunto rico y completo de funciones. Para que esto sea posible, Spring Data JPA le permite crear interfaces estereotipadas inteligentes de Spring Repository.

Estos Repositorios son interfaces Java que le permiten a usted, como desarrollador, definir un contrato de acceso a datos. El marco Spring Data JPA luego puede inspeccionar ese contrato y construir automáticamente la implementación de la interfaz bajo las cubiertas para usted.

Para que Spring Data JPA genere de manera inteligente una implementación de su interfaz de repositorio, se necesita un DSL de consulta.

DSL es un acrónimo de Idioma específico del dominio. El Lenguaje específico de dominio de consulta le permite crear métodos de interfaz Java que utilizan ciertas palabras clave junto con atributos de entidad JPA para realizar el trabajo necesario para implementar correctamente sus consultas sin tener que proporcionar mucho en la forma de codificación real. También cubriremos casi todo lo que necesita saber sobre las especificaciones de Query DSL.

Y por último, Spring Data JPA proporciona algunos extras agradables que a menudo se ven y usan en las capas de acceso a datos en niveles persistentes. Las funciones como la auditoría, la paginación y el manejo de consultas SQL nativas se pueden utilizar con el marco Spring Data JPA. Si por alguna razón, Spring Data JPA no puede proporcionar una solución para una de sus necesidades de capa de acceso a datos, puede quitarse del camino fácilmente y permitirle codificar o trabajar en paralelo, o fuera del marco por completo. , sin pisar los dedos de los pies.

Antes de comenzar {#antes de comenzar}

Antes de entrar en más detalles con Spring Data JPA, quiero hablar sobre lo que este artículo no cubrirá. En primer lugar, no profundizaremos en JPA y ORM, ni en los conceptos de mapeo relacional de objetos.

De hecho, estos temas son lo suficientemente amplios como para justificar sus propios cursos y tutoriales. Tampoco profundizaremos en Relaciones, como “uno a muchos”, “muchos a muchos”, “muchos a uno”, etc. Esos temas están bien cubiertos en los otros cursos y tutoriales de JPA. Tampoco entraremos en las estructuras SQL, JDBC, JPAQL y NoSQL.

Utilizaremos JPAQL en este artículo cuando hablemos sobre Spring Data JPA Query DSL, por lo que tener un conocimiento básico de SQL y JPAQL definitivamente será beneficioso. Y por último, no cubriremos conceptos de Core Spring como Inyección de dependencia, el contexto y contenedor de Spring, y la configuración básica de Spring.

También cubriremos algunos ejemplos de código para ganar experiencia y comprensión de Spring Data JPA a lo largo de este artículo.

Necesitará herramientas como Java, Maven y un IDE (IntelliJ, Eclipse o NetBeans) para configurar en su máquina de desarrollo para aprovechar al máximo este artículo.

Elegir una capa de acceso a datos de Java

Siempre que esté creando o trabajando en una capa de acceso a datos o un nivel de persistencia, tiene una variedad de opciones que puede usar. Quiero tomarme un minuto para hablar sobre estas opciones para ayudarlo a ver dónde Spring Data JPA puede encajar arquitectónicamente. También debe darse cuenta de que ningún marco o API suele funcionar para todo. Y las mejores capas de acceso a datos suelen ser un híbrido de marcos.

Si está trabajando con una base de datos realmente simple con quizás solo unas pocas tablas o tiene muchas necesidades de SQL nativo, entonces algunos marcos de capa de acceso a datos pueden ser una exageración. Usar directamente JDBC o Spring JDBC con Native SQL puede ser su mejor y más simple opción. A veces, sus informes deben dictar una determinada capa de acceso a datos, y JDBC o Native SQL pueden funcionar mejor para eso.

Si tiene una aplicación que necesita realizar muchas inserciones, actualizaciones o eliminaciones de SQL, querrá obtener un marco que se especialice en esa funcionalidad en particular. JPA no es un gran candidato para grandes cantidades de escrituras en su almacén de datos. La razón por la que JPA u ORM en general luchan con escrituras grandes es que la naturaleza del marco requiere que cree el gráfico de su objeto en la memoria, luego lo actualice con los valores modificados y luego lo guarde en su almacenamiento de datos.

Si está trabajando con árboles de gráficos realmente grandes, esto puede ser bastante costoso en términos de tiempo y terminar creando grandes huellas de memoria en su servidor. En su lugar, probablemente debería buscar un marco que maneje el procesamiento por lotes específicamente. Por ejemplo, un marco como Spring Batch o Hadoop. Java EE 7 también contiene un componente de escritura por lotes como parte de su funcionalidad principal ahora. Asegúrese de tener todo en cuenta cuando esté creando su arquitectura y pila iniciales para su aplicación Java.

Instalación de Spring Data JPA

Avancemos e instalemos y configuremos Spring Data JPA. Primero, necesitaremos agregar la dependencia JPA de Spring Data en la ruta de clase de nuestra aplicación.

Dado que estamos usando Maven para manejar nuestras dependencias, podemos agregar este bloque de dependencia en nuestro archivo pom.xml.

A continuación, deberá indicarle a Spring que configure y cargue los repositorios JPA. Aquí es donde ocurre la mayor parte de la magia de Spring Data JPA. Este paso en la instalación de Spring Data JPA es donde obtiene su interfaz de repositorio implementada bajo las sábanas cuando se inicia su aplicación. Si está utilizando la configuración XML de Spring, debe agregar esta declaración jpa:repositories en el archivo XML de contexto de su aplicación, por ejemplo: <jpa:repositories base-package="com.demo.repositores"/> .

El atributo base-package le dice a Spring Data JPA qué paquetes debe escanear para buscar repositorios JPA. Debe establecer el paquete base en la estructura del paquete raíz de su proyecto, o un paquete que se sabe que contiene sus repositorios JPA.

La otra forma de configurar Spring Data JPA es usar la anotación @EnableJpaRepositories. Esta es la forma preferida si está utilizando Spring Boot o una configuración de Java con Spring en lugar de una configuración XML.

Repositorios Spring

Spring ha apoyado el concepto de un repositorio desde hace algún tiempo. Repositorio es uno de los estereotipos principales de Spring\ y debe planear usarlos en su capa de acceso a datos, independientemente de la API y el marco de la capa de acceso a datos elegidos.

El objetivo del repositorio es definir un contrato que implementará su capa de acceso a datos. Este contrato, o más bien la interfaz, puede incluirse y vincularse mediante el código del cliente que necesita acceder a los datos de alguna manera. Lo que esto realmente significa es que un repositorio Spring es esencialmente una implementación del patrón Objeto de acceso a datos.

Al definir una interfaz que usa el código de superficie, la capa de acceso a datos es libre de implementar el contrato DAO de todos modos.

{.img-responsive}

Eso puede significar que cuando comenzó su proyecto implementó su capa de acceso a datos con JPA. Tal vez en algún momento más adelante en el proyecto, necesitaba reemplazar esa implementación con la implementación de JDBC en lugar de JPA. Cuando cambia la implementación de la interfaz, el código de servicio al cliente ni siquiera notó ni se preocupó de que algo cambiara en cuanto a la implementación en su capa de acceso a datos. Y quién sabe, tal vez en algún momento en el futuro, deba cambiar su implementación de JDBC por otra. Este patrón le permite configurar capas híbridas de acceso a datos.

Su implementación puede hacer algunas operaciones utilizando JPA mientras utiliza JDBC para otras operaciones. La definición más pura de un patrón DAO diría que necesita definir un contrato con una interfaz. Sin embargo, los repositorios de Spring no necesariamente tienen que ser una interfaz.

Descripción general de la arquitectura del repositorio

Los repositorios encajan en la capa de acceso a datos, pero no son los únicos objetos y conceptos que debe tener en cuenta cuando trabaja en el lado del servidor. Veamos una aplicación típica de Spring desde el punto de vista de la arquitectura para ver cómo podría encajar todo.

Su base de datos generalmente consta de una o más tablas. Pueden o no estar relacionados, como una relación de padre o hijo. Todas estas estructuras viven en la base de datos, que suele ser un servidor independiente separado del código de la aplicación y del servidor.

A medida que avanzamos en nuestra capa de acceso a datos, tenemos entidades JPA asignadas a tablas de bases de datos. Las entidades se mapean una a una con un repositorio JPA. Al mantener el repositorio enfocado en una sola entidad, mantiene el patrón DAO limitado a esa estructura de datos y datos específicos.

Con los repositorios estándar de Spring, no tiene que seguir este estándar. Técnicamente, puede hacer que el repositorio acceda a cualquier cosa y todo en el lado de los datos. Pero con los repositorios JPA de datos de Spring, el repositorio está limitado a una sola entidad JPA.

Los servicios de Spring se pueden usar para realizar paquetes lógicos de trabajo para la aplicación. La anotación @Service de Spring es otro estereotipo de Spring y lo usaría en clases e interfaces que viven en su capa de servicio.

Y por último, su aplicación generalmente tendrá algún tipo de capa de controlador que maneja el enrutamiento de solicitudes que ingresan desde la interfaz de usuario. Estos controladores pueden utilizar uno o más servicios y son responsables de devolver una respuesta a la interfaz de usuario o al nivel de presentación.

Nota: Lo importante que debe recordar es que las dependencias y enlaces de su código solo deben moverse hacia la derecha en este diagrama. Entonces, los controladores pueden inyectar servicios o repositorios y los servicios pueden inyectar repositorios, pero los servicios y repositorios nunca deben inyectar controladores.

{.img-responsive}

Repositorios Spring Data JPA

Está empezando a ver que los repositorios Spring estándar y los repositorios Spring Data JPA difieren ligeramente en concepto y estructura.

Aquí están las principales diferencias:

  • Interfaz Java en lugar de una clase.
  • Mapa 1 a 1 con una entidad JPA
  • Foco en contrato DAO

Primero, todos los repositorios JPA son interfaces Java en lugar de clases. Estas interfaces están asociadas con una entidad JPA. Cada repositorio JPA solo puede realizar operaciones de acceso a datos para esa entidad en particular y sus atributos de datos. Esto ayuda a enfocar el repositorio JPA en el contrato DAO para esa entidad y sus datos de respaldo. ¿Cómo se vinculan los repositorios de JPA con una entidad de JPA en particular? Esto se logra usando genéricos de Java y escribiendo:

1
public interface MyJpaRepository extends JpaRepository<Entity, Id Type> {}

Al proporcionar la entidad JPA y su tipo de datos de clave principal, el repositorio JPA ahora sabe exactamente con qué tabla de base de datos en columnas puede trabajar porque toda esa información está muy bien agrupada dentro de su entidad JPA.

La última gran diferencia entre los repositorios Spring Data JPA y los repositorios Spring estándar es cómo la implementación cumple con el patrón DAO.

El patrón DAO le permite implementar el contrato DAO como quiera, y esa implementación depende de usted. Con los repositorios Spring Data JPA, ya no nos preocupamos por los detalles de implementación, ya que el marco nos lo proporcionará. Esto nos permite, como desarrolladores, centrarnos en el contrato DAO mientras cumplimos el objetivo de Spring Data JPA de simplificar nuestra capa de acceso a datos sin pérdida de funcionalidad.

Lo importante que debe recordar es que cuando se inicia su aplicación, Spring Data JPA reconoce su repositorio JPA y genera automáticamente una implementación para el contrato DAO que se especifica en esa interfaz.

Características de JpaRepository

Cuando amplía la interfaz del repositorio JPA, también obtiene acceso a muchas otras funciones. La funcionalidad que viene con el repositorio JPA incluye las operaciones CRUD que verá más adelante en los ejemplos de código y también contiene la funcionalidad Query DSL que cubriremos más adelante en este artículo.

Funcionalidad

  • Consulta DSL
  • Operaciones CRUD
  • Paginación y clasificación
  • Ayudantes
    • count()
    • exists(Long id)
    • flush()
    • deleteInBatch(Iterable entities)

También hay capacidades de paginación y clasificación, y por último, el repositorio JPA contiene algunos ayudantes que pueden facilitar mucho el trabajo con su capa de acceso a datos. Algunos de estos incluyen encontrar el recuento de su tabla de base de datos de respaldo, probar si existe un registro en la base de datos, descargar sus cambios de contexto de persistencia en la base de datos y manejar la eliminación de múltiples entidades con una sola consulta usando el práctico método deleteInBatch().

{.img-responsive}

Si echa un vistazo a la jerarquía de la interfaz del repositorio JPA, verá que hay tres interfaces principales más desde las que se extiende el repositorio JPA.

Verá que cuando se combina en una estructura jerárquica, toda la funcionalidad de la que hemos hablado para el repositorio JPA comienza a tener sentido. Lo bueno de dividir la funcionalidad en interfaces separadas es que le brinda la oportunidad de reducir la funcionalidad en su capa de acceso a datos si es necesario.

Tal vez solo desee tener operaciones CRUD disponibles en su repositorio, por lo que, en ese caso, simplemente puede ampliar el repositorio CRUD en lugar del repositorio JPA. Una última cosa a tener en cuenta sobre la jerarquía del repositorio JPA es que la interfaz JpaRepository es la única interfaz en el proyecto Spring Data JPA. Las otras tres interfaces en realidad provienen del proyecto principal de datos de Spring.

Ejemplo de código

En esta sección, vamos a crear un ejemplo simple de Spring Boot para que podamos implementar Spring Data JPA y REST dentro de nuestra aplicación.

Elija su IDE favorito (por ejemplo, Eclipse e IntelliJ IDEA tienen Spring Initializr incorporado para las dependencias de configuración). Para generar el proyecto Spring Boot, puede consultar [Spring Initializr] (https://start.spring.io/) y también para iniciar su aplicación con dependencias.

En el archivo pom.xml, agregamos algunas dependencias más para nuestro proyecto simple, como spring-web que nos proporciona Spring MVC y Spring Rest, [base de datos H2](/integrando- la-base-de-datos-h2-con-spring-boot/) y JPA:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<dependencies>

    <!-- JPA dependency-->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-jpa</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <dependency>
        <groupId>com.h2database</groupId>
        <artifactId>h2</artifactId>
        <scope>runtime</scope>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>

</dependencies>

Creamos una clase de controlador llamada UserController que contiene la anotación @RestContoller. Esta anotación le dice a Spring MVC que este es el controlador y que tiene un punto final de descanso. Es prácticamente el equivalente a escribir tanto @Controller como @ResponseBody.

El controlador también contiene @RequestMapping("/users") para asignar una solicitud HTTP a un método o una clase, un método GET, un método POST y un objeto @Autowired UserJpaRepository.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
@RestController
@RequestMapping("/users")
public class UserController {

    @Autowired
    private UserJpaRepository userJpaRepository;

    @GetMapping(value = "/all")
    public List<Users> getAll(){
        return userJpaRepository.findAll();
    }

    @PostMapping(value = "/load")
    public Users load(@RequestBody final Users users) {
        return userJpaRepository.save(users);
    }
}

Ahora, ¿cómo obtenemos los datos de la base de datos? Pasemos a la definición de la interfaz del repositorio UserJpaRepository que extiende 'JpaRepository'.

Dentro de JpaRepository<Users, Long> pasamos el modelo y su Id. En el ejemplo del controlador, estamos usando 'findAll()' para obtener todos los registros de la base de datos y 'save()' para guardarlos.

1
public interface UserJpaRepository extends JpaRepository<Users, Long> {}

La clase de modelo Usuarios será nuestra entidad. La clase en sí está anotada con @Entity, la variable id está anotada con @Id y @GeneratedValue.

  • La anotación @Entity asignará este POJO a la base de datos con todos sus campos.
  • La anotación @Id marca el campo como la clave principal de la tabla.
  • La anotación @GeneratedValue prácticamente establece la opción AUTO_INCREMENT de la clave principal en verdadero. Opcionalmente, puede agregar (strategy = GenerationType.AUTO) para lograr esto.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
@Entity
public class Users {

    @Id
    @GeneratedValue
    private Long id;

    private String name;
    private Integer salary;

    // getters and setter
}

Después de iniciar la aplicación, vaya a 'localhost:8080/users/all' para obtener todos los usuarios, y no debería recibir nada como puede ver en la imagen a continuación porque no tiene ningún usuario en la memoria H2 base de datos.

{.img-responsive}

A continuación, vaya a su herramienta de cliente REST favorita (la imagen a continuación muestra un ejemplo de Cartero). Como puede notar, estamos usando el método POST de nuestro controlador que guardará los datos.

Agregamos nombre y salario y enviamos la solicitud POST. El id se genera automáticamente como puede ver en el cuerpo de la respuesta.

La aplicación respondió con un Estado 200 OK. ¡Todo está funcionando como debería! De esta manera, puede agregar tantos usuarios como desee.

Nota: Después de reiniciar la aplicación, se perderán todos los datos porque estamos usando una base de datos en memoria.

{.img-responsive}

Ahora vaya a localhost:8080/users/all de nuevo para OBTENER todos los registros de usuario de la base de datos y debería ser recibido con:

{.img-responsive}

Consultar descripción general de DSL

De todas las funciones que proporciona Spring Data JPA, la función Query DSL en el repositorio de JPA es una de las más potentes, flexibles y pertinentes para las necesidades de consulta y lectura de acceso a datos de su aplicación.

Debido a que Query DSL es extremadamente personalizable y se basa en su entidad JPA, también puede ser uno de los aspectos más difíciles de Spring Data JPA para aprender y volverse eficiente.

Ventajas de usar un DSL de consulta

Algunas de las ventajas de usar un Query DSL es que le permitirá sobrescribir búsquedas y búsquedas personalizadas.

Primero, piense en todos los esfuerzos que ha invertido en mapear entidades JPA a las tablas de su base de datos. Si tiene un esquema de base de datos grande, configurar sus entidades JPA puede llevar algo de trabajo. Su capa de entidad contiene mucha información sobre las tablas de la base de datos a las que se asigna.

Por ejemplo, JPA conoce el nombre de la tabla, las columnas y los tipos de datos de las columnas al observar las anotaciones de su entidad, los atributos y los tipos de datos de los atributos. Si ha hecho un esfuerzo adicional con el mapeo de su entidad, puede especificar restricciones en las relaciones que le brindan aún más conocimiento sobre su base de datos desde el nivel del software. ¿Por qué tirar todo este conocimiento para tener que implementar consultas y buscadores manualmente?

Deje que un marco como Spring Data JPA use esta información para que pueda definir el contrato de consulta y dejar que el marco proporcione la implementación. Debido a que no estamos agregando código de implementación, eso nos libera como desarrolladores de aplicaciones de tener que mantener ese código.

Con el tiempo, recolecta herramientas y otros artículos diversos y, después de un tiempo, se encontrará limpiando, ordenando y organizando su garaje un sábado. Por lo tanto, desde el punto de vista del desarrollo de aplicaciones, no pierda su valioso tiempo del sábado limpiando su garaje. Deje que Spring Data JPA se ocupe de su problema de implementación mientras va de pesca o hace otra cosa.

Otra ventaja de ahorro de tiempo de usar Spring Data JPA Query DSL es que el marco verifica la validez de sus consultas cuando se inicia su aplicación, en lugar de en tiempo de ejecución. Esto ahorra tiempo de tener que buscar y probar el punto en su aplicación al que llamó la consulta.

Las comprobaciones de inicio de la aplicación también protegen contra los cambios de refactorización. Si cambia un atributo de entidad, sabrá rápidamente si eso interrumpió alguna de sus consultas cuando inicie su aplicación.

Por último, los DSL de consulta se han utilizado en plataformas de lenguaje con secuencias de comandos durante mucho tiempo. El marco de trabajo de registro activo de Ruby on Rails o la pila ORM de Django son buenos ejemplos de esto. Java ha tardado en adoptar esta metodología debido a su naturaleza compilada y de verificación de tipos. Es fácil agregar funcionalidad sobre la marcha en un lenguaje de secuencias de comandos porque los clientes que lo usan no están verificados ni compilados.

Esto le da a los lenguajes escritos mucha flexibilidad en esta área en particular. Spring Data JPA ha encontrado un equilibrio bastante bueno al requerir que el desarrollador defina el contrato de datos, y luego el marco puede implementar ese contrato como lo harían Rails o Django. El código del cliente puede vincularse y compilarse contra ese contrato de interfaz.

Y antes de continuar, asegurémonos de que tenemos claro qué es un DSL. DSL es un acrónimo de Ddominio Sespecífico Lidioma. Este es un término utilizado para clasificar una extensión de un lenguaje de programación para abordar un dominio. En el caso de Spring Data JPA, esto significa que el marco está mejorando Java para que sea más adecuado para crear y trabajar con consultas JPA.

Usamos lenguaje específico de dominio en el habla todo el tiempo. Los médicos tienen términos y palabras que los ayudan a trabajar de manera más eficiente, y lo mismo ocurre con los abogados o los trabajadores de la construcción, o cualquier industria. Spring Data JPA Query DSL se trata simplemente de definir términos y sintaxis para trabajar con consultas JPA de manera más eficiente.

Sintaxis del método de consulta

Repasemos los conceptos básicos de la sintaxis necesaria para que estos métodos de consulta funcionen. Primero, los métodos de consulta son simplemente métodos definidos en su repositorio JPA que Spring Data JPA implementará automáticamente en su nombre. Son una forma en que Spring Data JPA puede implementar consultas por usted.

Cuando crea un método de consulta, el analizador de consultas buscará métodos que comiencen con find, query, read, count o get. Estos prefijos se pueden mejorar con otras palabras clave hasta que, finalmente, llegue a B-Y o By, una sección del nombre del método.

Esto indica que el criterio, o parte del filtro, de la consulta está comenzando y Spring Data JPA hace coincidir los atributos de entidad de los criterios del método con la cláusula ‘WHERE’ real en su SQL Se pueden agregar múltiples definiciones de criterios a su nombre de método con las palabras clave ‘Y’ o ‘O’.

Esto puede sonar un poco confuso, así que veamos la consulta de ubicación en el código a continuación.

1
2
3
public interface LocationJpaRepository extends JpaRepository<Location, Long> {
    findByAgeLike(Integer age);
}
  • find: el método comienza con find para que el analizador de consultas entienda que necesita implementar este contrato de consulta.

  • Por - Después de la palabra clave anterior, agregamos esta que indica que la información de los criterios vendrá a continuación en el nombre del método.

  • Edad - Luego, lo especificamos más. Age coincide con el nombre del atributo age en mi entidad JPA de ubicación, y age es del tipo de datos Integer.

  • Me gusta: la palabra clave final le dice a la implementación que queremos crear una consulta Me gusta, en lugar de una coincidencia exacta.

Luego paso una variable Integer que la implementación de la consulta debería usar como criterio de filtro real. Es de tipo ‘Entero’ porque nuestro tipo de datos de edad en la entidad de ubicación es de tipo ‘Entero’.

Al juntar las palabras clave de DSL de consulta con la tipificación genérica del repositorio JPA, puede ver cómo Spring Data JPA puede generar el JPQL para nosotros.

Esto, a su vez, se asigna al SQL real que se emitirá en la base de datos gracias al marco JPA ORM.

Palabras clave

Fragmento de JPQL de muestra de palabra clave


Y findByLastnameAndFirstname ...where x.lastname = ?1 and x.firstname = ?2 O findByLastnameOrFirstname ...where x.lastname = ?1 o x.firstname = ?2 Es igual a findByFirstnameEquals ...where x.firstname = ?1 Entre findByStartDateBetween ...donde x.startDate entre ?1 y ? LessThan findByAgeLessThan ...donde x.edad < ?1 LessThanEqual findByAgeLessThanEqual ...donde x.edad <= ?1 GreaterThan findByAgeGreaterThan ...donde x.edad > ?1 GreaterThanEqual findByAgeGreaterThanEqual ...donde x.edad >= ?1 Después de findByStartDateAfter ...where x.startDate > ?1 Antes de findByStartDateBefore ...where x.startDate < ?1 IsNull findByAgeIsNull ...donde x.age es nulo IsNotNull, NotNull findByAge(Is)NotNull ...donde x.age no es nulo Como findByFirstnameLike ...where x.firstname like ?1 NotLike findByFirstnameNotLike ...where x.firstname not like ?1 Empezando con findByFirstnameStartingWith ...donde x.firstname como? 1 (parámetro enlazado con %) adjunto EndingWith findByFirstnameEndingWith ...where x.firstname like ?1 (parámetro enlazado con %) Conteniendo findByFirstnameContaining ...where x.firstname like ?1 (límite de parámetro envuelto en %) OrderBy findByAgeOrderByLastnameDesc ...where x.age = ?1 ordenar por x.lastname desc No findByLastnameNot ...where x.lastname <> ?1 En findByAgeIn(Colección de edades) ...donde x.edad en ?1 NotIn findByAgeNotIn(Colección de edades) ...donde x.edad no está en ?1 True findByActiveTrue() ...donde x.active = true Falso findByActiveFalse() ...donde x.active = falso IgnoreCase findByFirstnameIgnoreCase ...donde UPPER(x.firstname) = UPPER(?1) ?1)