Muestra las diferencias entre dos versiones de la página.
Próxima revisión | Revisión previa | ||
simo:documentos:tecnicos:repositorios [2017/10/18 02:58] lgomez creado |
simo:documentos:tecnicos:repositorios [2017/10/25 03:48] (actual) lgomez |
||
---|---|---|---|
Línea 4: | Línea 4: | ||
Los repositorios SIMO se basan en los repositorios Spring Data JPA, si bien los repositorios Spring Data JPA proporcionan funcionalidad CRUD básica, SIMO ha extendido estas funcionalidades mediente el uso de herencia y tipos genéricos con el objeto de incluir operaciones adicionales, estas operaciones incluyen operaciones de búsqueda avanzada basadas en Hibernate Search y operaciones optimizadas para el despliegue de listas, entre otras. En el siguiente diagrama se muestra la estructura de herencia de un repositorio SIMO que a su vez sirve para ilustrar el camino de evolución desde un repositorio Spring Data JPA hasta un repositorio SIMO. | Los repositorios SIMO se basan en los repositorios Spring Data JPA, si bien los repositorios Spring Data JPA proporcionan funcionalidad CRUD básica, SIMO ha extendido estas funcionalidades mediente el uso de herencia y tipos genéricos con el objeto de incluir operaciones adicionales, estas operaciones incluyen operaciones de búsqueda avanzada basadas en Hibernate Search y operaciones optimizadas para el despliegue de listas, entre otras. En el siguiente diagrama se muestra la estructura de herencia de un repositorio SIMO que a su vez sirve para ilustrar el camino de evolución desde un repositorio Spring Data JPA hasta un repositorio SIMO. | ||
+ | |||
+ | {{simo:documentos:tecnicos:repository.png}} | ||
+ | |||
+ | En su versión más sencilla, un repositorio Spring Data JPA es una interfaz que extiende de [[https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/repository/CrudRepository.html|CrudRepository]], al hacerlo, el framework Spring produce una implementación por defecto que incluye los métodos básicos de esta interfaz y que escencialmente son los métodos CRUD tradicionales. Nótese que el repositorio recibe un parámetro de tipo que es la entidad JPA que maneja el repositorio, es decir que los métodos CRUD quedan parametrizados para manejar una entidad en particular. | ||
+ | |||
+ | Otra característica muy importante de los repositorios Spring Data JPA, es la capacidad de crear métodos finder o incluso métodos delete, update e insert, sin necesidad de escribir su implementación. Símplemente al escribir la declaración del método, el framework es capaz de construir la lógica a partir del nombre del método bajo unas convenviones establecidas, o a través de sentencias JPQL especificadas mediante la anotación @Query. | ||
+ | |||
+ | La siguiente interfaz en el sistema de herencia es [[https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/repository/PagingAndSortingRepository.html|PagingAndSortingRepository]], esta interfaz actua de forma similar a CrudRepository pero proporciona versiones de los métodos CRUD capaces de manejar paginación y ordenamiento. Al igual que en el caso de CrudRepository, un repositorio Spring Data JPA solo necesita extender la interfaz para que el framework provea toda la interfaz. | ||
+ | |||
+ | Las siguientes clases e interfaces en el sistema de herencia ya no hace parte de el framework Spring, y por tanto, es en este punto donde un repositorio SIMO se empieza a diferenciar de un repositorio Spring Data JPA. | ||
+ | |||
+ | La primera de ellas es SearchableRepository, esta interfaz define métodos orientados a proporcionar al repositorio capacidades de búsqueda. Se definen tres métodos pricipales, con sus respectivas versiones paginadas | ||
+ | |||
+ | * **findByQuery: ** Encuentra entidades utilizando JPA (Criteria) | ||
+ | * **search: ** Encuentra entidades utilizando Hibernate Search y Lucene | ||
+ | * **find: ** Encuentra entidades con base en la propiedad search_mode del sistema (0 utiliza search, 1 utiliza preferiblemente search y si hay un error utiliza findByQuery, 2 utiliza findByQuery | ||
+ | La segunda interfaz es ListableRepository y define métodos para listar conjuntos de entidades (para ser usados en controles de tipo ComboBox o List o Select), estos métodos se diferencian de los de búsqueda principalmente en que están orientados a buscar por un solo campo en la entidad (generalmente es el campo nombre) con el fin de soportar funciones de autocompletar. Esta interfaz define los siguientes dos métodos: | ||
+ | |||
+ | * **listByQuery: ** Lista entidades usando JPA | ||
+ | * **list: ** Lista entidades usando Hibernate Search y Lucene o JPA según el parámetro search_mode | ||
+ | |||
+ | Al incluir interfaces distintas a las proporcionadas por Spring, se hace necesario tener una implementación, la clase SearchableRepositoryImpl contiene una implementación por defecto y es por ello que para construir un Repositorio Simo, solo se necesita la interfaz principal (Que extiende de PagingAndSortingRepository, SearchableRepository y ListableRepository) y una clase concreta que extienda de SearchableRepositoryImpl y que por tanto contiene la implementación de los métodos definidos en las interfaces propias. | ||
+ | |||
+ | Nótese sin embargo que aún se necesita dar implementación a los métodos de PagingAndSortingRepository e indirectamente de CrudRepository, en adición a los métodos finder definidos en la interfaz principal, como se expuso anteriormente, de esto se encarga el framework, al detectar la anotación @Repository en la definición de la interfaz. | ||
+ | |||
+ | Es decir que la implementación concreta proviene de dos fuentes, la primera es el framework y es transparente al programador, la segunda es una clase concreta llamada de igual forma a la interfaz principal pero terminando en el sufijo Impl. Ejemplo: El repositorio SIMO para la entidad convocatoria se compone de la interfaz ConvocatoriaRepository y la clase concreta ConvocatoriaRepositoryImpl. | ||
+ | |||
+ | Otro detalle importante es que la clase concreta no implementa directamente la interfaz principal, pues si lo hiciera, tendría que dar implementación también a los métodos declarados en ella y a los métodos contenidos en PagingAndSortingRepository, de esta forma se perderían las facilidades otorgadas por el framework. Al no haber una implementación directa (mediante la palabra clave **//implements//**, el framework debe inferir que clase concreta utilizar, y lo hace por convención buscando una clase de igual nombre a la interfaz pero con el sufijo Impl. | ||
+ | |||
+ | Nótese también que la clase concreta no necesita en sí escribir métodos puesto que al heredar de SearchableRepositoryImpl ya tiene una implementación por defecto, sin embargo, es en esta clase concreta donde se pueden sobreescribir métodos de su clase madre para dar implementación específicas a la entidad que se está manejando en el repositorio, y este el caso que más se encuentra en SIMO | ||