Dos Ideas. - Contribuciones del usuario [es]

Simple XML

2013-01-25T17:03:25Z

Barrios.nahuel: /* Ver también */

==Otro parser XML==
Ese es el punto. ¿Por qué otro des/serializador de XML > Java | Java > XML? Para conocer otra herramienta, con sus pros y contras, que en alguna situación pueda resultar ser una mejor opción que otro como [[XStream]], por ejemplo.

Si siguen leyendo vamos a ver como agregar esta biblioteca utilitaria y unos ejemplos de uso básicos y muy sencillos.

==Agregar dependencia==
Para agregar la dependencia, utilizando Maven, es suficiente con:
<dependency>
<groupId>org.simpleframework</groupId>
<artifactId>simple-xml</artifactId>
<version>2.6.9</version>
</dependency>

* Se puede ver cuál es la última version disponible [http://mvnrepository.com/artifact/org.simpleframework/simple-xml desde acá]

==La entidad==

import org.simpleframework.xml.Element;

public class Persona {
@Element
private String identidad;
@Element
private int edad;
}

==Serializar (Java > XML)==

===El método===
public String obtenerXml(Persona persona) throws Exception {
Serializer serializer = new Persister();
ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
serializer.write(persona, outputStream);
return outputStream.toString();
}

* '''Nota''': El método write(), para la version de este ejemplo, se puede llamar con:
** java.io.File
** java.io.OutputStream
** java.io.Writer
** org.simpleframework.xml.stream.OutputNode

===Resultado===

<persona>
<identidad>34123456</identidad>
<edad>15</edad>
</persona>

==Deserializar (XML > Java)==

===El método===
public Persona crear(String xml) throws Exception {
Serializer serializer = new Persister();
return serializer.read(Persona.class, xml);
}

* '''Nota''': Vale mencionar que para deserializar un objeto es necesario que exista el constructor por default sin parámetros. De no hacerlo, lanzará una excepción:

org.simpleframework.xml.core.PersistenceException: Constructor not matched for class {miClase}

==Alternativas para des/serialización de XML==
*XStream
** [[XStream | En esta wiki]].
** [http://xstream.codehaus.org/ Sitio web oficial].

==Ver también==
* [http://simple.sourceforge.net/home.php Sitio web oficial de Simple XML Framework].
** [http://simple.sourceforge.net/download/stream/doc/tutorial/tutorial.php Tutoriales desde el sitio oficial de Simple XML Framework]
** [http://simple.sourceforge.net/download/stream/doc/examples/examples.php Ejemplos más complejos desde el sitio oficial de Simple XML Framework]
* Proyecto de ejemplo (el código de este tutorial, con ejemplos funcionando más complejos):
** SVN: http://dosideas-aplicaciones-modelo.googlecode.com/svn/test-simpleXmlFramework
** Web: http://code.google.com/p/dosideas-aplicaciones-modelo/source/browse/#svn%2Ftest-simpleXmlFramework

Simple XML

2013-01-25T17:02:42Z

Barrios.nahuel: /* La entidad */

==Otro parser XML==
Ese es el punto. ¿Por qué otro des/serializador de XML > Java | Java > XML? Para conocer otra herramienta, con sus pros y contras, que en alguna situación pueda resultar ser una mejor opción que otro como [[XStream]], por ejemplo.

Si siguen leyendo vamos a ver como agregar esta biblioteca utilitaria y unos ejemplos de uso básicos y muy sencillos.

==Agregar dependencia==
Para agregar la dependencia, utilizando Maven, es suficiente con:
<dependency>
<groupId>org.simpleframework</groupId>
<artifactId>simple-xml</artifactId>
<version>2.6.9</version>
</dependency>

* Se puede ver cuál es la última version disponible [http://mvnrepository.com/artifact/org.simpleframework/simple-xml desde acá]

==La entidad==

import org.simpleframework.xml.Element;

public class Persona {
@Element
private String identidad;
@Element
private int edad;
}

==Serializar (Java > XML)==

===El método===
public String obtenerXml(Persona persona) throws Exception {
Serializer serializer = new Persister();
ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
serializer.write(persona, outputStream);
return outputStream.toString();
}

* '''Nota''': El método write(), para la version de este ejemplo, se puede llamar con:
** java.io.File
** java.io.OutputStream
** java.io.Writer
** org.simpleframework.xml.stream.OutputNode

===Resultado===

<persona>
<identidad>34123456</identidad>
<edad>15</edad>
</persona>

==Deserializar (XML > Java)==

===El método===
public Persona crear(String xml) throws Exception {
Serializer serializer = new Persister();
return serializer.read(Persona.class, xml);
}

* '''Nota''': Vale mencionar que para deserializar un objeto es necesario que exista el constructor por default sin parámetros. De no hacerlo, lanzará una excepción:

org.simpleframework.xml.core.PersistenceException: Constructor not matched for class {miClase}

==Alternativas para des/serialización de XML==
*XStream
** [[XStream | En esta wiki]].
** [http://xstream.codehaus.org/ Sitio web oficial].

==Ver también==
* [http://simple.sourceforge.net/home.php Sitio web oficial de Simple XML Framework].
** [http://simple.sourceforge.net/download/stream/doc/tutorial/tutorial.php Tutoriales desde el sitio oficial de Simple XML Framework]
** [http://simple.sourceforge.net/download/stream/doc/examples/examples.php Ejemplos más complejos desde el sitio oficial de Simple XML Framework]
* Proyecto de ejemplo (el código de este tutorial):
** SVN: http://dosideas-aplicaciones-modelo.googlecode.com/svn/test-simpleXmlFramework
** Web: http://code.google.com/p/dosideas-aplicaciones-modelo/source/browse/#svn%2Ftest-simpleXmlFramework

Simple XML

2013-01-22T19:50:39Z

Barrios.nahuel: Agrego la URL del repositorio en Google Code para el proyecto que agregue de Simple XML

==Otro parser XML==
Ese es el punto. ¿Por qué otro des/serializador de XML > Java | Java > XML? Para conocer otra herramienta, con sus pros y contras, que en alguna situación pueda resultar ser una mejor opción que otro como [[XStream]], por ejemplo.

Si siguen leyendo vamos a ver como agregar esta biblioteca utilitaria y unos ejemplos de uso básicos y muy sencillos.

==Agregar dependencia==
Para agregar la dependencia, utilizando Maven, es suficiente con:
<dependency>
<groupId>org.simpleframework</groupId>
<artifactId>simple-xml</artifactId>
<version>2.6.9</version>
</dependency>

* Se puede ver cuál es la última version disponible [http://mvnrepository.com/artifact/org.simpleframework/simple-xml desde acá]

==La entidad==

import org.simpleframework.xml.Element;
import org.simpleframework.xml.Root;

@Root
public class Persona {
@Element
private String identidad;
@Element
private int edad;
}

==Serializar (Java > XML)==

===El método===
public String obtenerXml(Persona persona) throws Exception {
Serializer serializer = new Persister();
ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
serializer.write(persona, outputStream);
return outputStream.toString();
}

* '''Nota''': El método write(), para la version de este ejemplo, se puede llamar con:
** java.io.File
** java.io.OutputStream
** java.io.Writer
** org.simpleframework.xml.stream.OutputNode

===Resultado===

<persona>
<identidad>34123456</identidad>
<edad>15</edad>
</persona>

==Deserializar (XML > Java)==

===El método===
public Persona crear(String xml) throws Exception {
Serializer serializer = new Persister();
return serializer.read(Persona.class, xml);
}

* '''Nota''': Vale mencionar que para deserializar un objeto es necesario que exista el constructor por default sin parámetros. De no hacerlo, lanzará una excepción:

org.simpleframework.xml.core.PersistenceException: Constructor not matched for class {miClase}

==Alternativas para des/serialización de XML==
*XStream
** [[XStream | En esta wiki]].
** [http://xstream.codehaus.org/ Sitio web oficial].

==Ver también==
* [http://simple.sourceforge.net/home.php Sitio web oficial de Simple XML Framework].
** [http://simple.sourceforge.net/download/stream/doc/tutorial/tutorial.php Tutoriales desde el sitio oficial de Simple XML Framework]
** [http://simple.sourceforge.net/download/stream/doc/examples/examples.php Ejemplos más complejos desde el sitio oficial de Simple XML Framework]
* Proyecto de ejemplo (el código de este tutorial):
** SVN: http://dosideas-aplicaciones-modelo.googlecode.com/svn/test-simpleXmlFramework
** Web: http://code.google.com/p/dosideas-aplicaciones-modelo/source/browse/#svn%2Ftest-simpleXmlFramework

Simple XML

2013-01-22T19:33:40Z

Barrios.nahuel: Creo una página nueva en la Wiki sobre Simple XML (framework para des/serializacion de XML)

==Otro parser XML==
Ese es el punto. ¿Por qué otro des/serializador de XML > Java | Java > XML? Para conocer otra herramienta, con sus pros y contras, que en alguna situación pueda resultar ser una mejor opción que otro como [[XStream]], por ejemplo.

Si siguen leyendo vamos a ver como agregar esta biblioteca utilitaria y unos ejemplos de uso básicos y muy sencillos.

==Agregar dependencia==
Para agregar la dependencia, utilizando Maven, es suficiente con:
<dependency>
<groupId>org.simpleframework</groupId>
<artifactId>simple-xml</artifactId>
<version>2.6.9</version>
</dependency>

* Se puede ver cuál es la última version disponible [http://mvnrepository.com/artifact/org.simpleframework/simple-xml desde acá]

==La entidad==

import org.simpleframework.xml.Element;
import org.simpleframework.xml.Root;

@Root
public class Persona {
@Element
private String identidad;
@Element
private int edad;
}

==Serializar (Java > XML)==

===El método===
public String obtenerXml(Persona persona) throws Exception {
Serializer serializer = new Persister();
ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
serializer.write(persona, outputStream);
return outputStream.toString();
}

* '''Nota''': El método write(), para la version de este ejemplo, se puede llamar con:
** java.io.File
** java.io.OutputStream
** java.io.Writer
** org.simpleframework.xml.stream.OutputNode

===Resultado===

<persona>
<identidad>34123456</identidad>
<edad>15</edad>
</persona>

==Deserializar (XML > Java)==

===El método===
public Persona crear(String xml) throws Exception {
Serializer serializer = new Persister();
return serializer.read(Persona.class, xml);
}

* '''Nota''': Vale mencionar que para deserializar un objeto es necesario que exista el constructor por default sin parámetros. De no hacerlo, lanzará una excepción:

org.simpleframework.xml.core.PersistenceException: Constructor not matched for class {miClase}

==Alternativas para des/serialización de XML==
*XStream
** [[XStream | En esta wiki]].
** [http://xstream.codehaus.org/ Sitio web oficial].

==Ver también==
* [http://simple.sourceforge.net/home.php Sitio web oficial de Simple XML Framework].
** [http://simple.sourceforge.net/download/stream/doc/tutorial/tutorial.php Tutoriales desde el sitio oficial de Simple XML Framework]
** [http://simple.sourceforge.net/download/stream/doc/examples/examples.php Ejemplos más complejos desde el sitio oficial de Simple XML Framework]

Desarrollando Android apps para distintas pantallas

2012-10-02T14:41:17Z

Barrios.nahuel: Desarrollando Android apps para distintas pantallas

=Términos y conceptos principales=

* Tamaño de la pantalla: El tamaño físico real de la pantalla medido diagonalmente.
* Densidad de la pantalla: Cantidad de píxels en una pulgada cuadrada de la pantalla. Dots per inch (dip).
* Orientación: Vertical/Horizontal (land/port)
* Resolución: La cantidad total de píxels que tiene la pantalla.
* Píxel independiente de la densidad (dp):
* Nomenclaturas: De las siguientes generalizaciones, se toma el tamaño normal, y la densidad medium como la estándar.

=Unidades disponibles=

==Dependientes del tamaño de la pantalla==

* Pulgadas (in)
* Puntos (pt): Un punto vale 1/72 de una pulgada.
* Milímetros (mm)

==Independientes del tamaño de la pantalla==

* Pixels (px): No se recomienda utilizar píxels porque la cantidad de píxels por pulgada varía entre distintos dispositivos.

* Density-independent pixels (dp): Es una unidad de medida virtual, que está basada en la densidad de la pantalla. Es relativa a una pantalla de tamaño normal y densidad mdpi como ya vimos más arriba que es el estándar. Al usar esta medida estamos permitiendo que el Sistema Operativo se encargue de redimensionar los elementos de la GUI de acuerdo a cada dispositivo, por lo tanto es aconsejable utilizar siempre esta unidad de medida.

* Scale-independent pixels (sp): Son como los dp, pero además están vinculados (escalados) al tamaño de la fuente que el usuario tiene asignada en el resto del dispositivo. Se debe usar esta unidad de medida siempre que se esté definiendo el tamaño de algún texto que se muestre en la GUI.

=Entendiendo cómo funciona=

El Sistema Operativo se encarga de agrupar los distintos tamaños de pantallas, para ello, cada una de las agrupaciones, tanto de tamaño como densidad abarca un rango finito de medidas. De esta manera, a una pantalla de 2 pulgadas, le corresponde el tamaño “small” y si la densidad es 180 le corresponderá “mdpi”.

=Alternativas para soportar múltiples pantallas=

* Explícitamente declarando en el Manifest.xml

En el archivo de manifiesto se puede especificar explícitamente para qué tamaños de pantallas se podrá instalar la aplicación. Es decír, aquellos dispositivos que no cumplan con esa especificación directamente no podrán instalar la aplicación.

* Distintos layouts para distintas pantallas

Si bien el sistema operativo redimensiona los layouts de acuerdo al tipo de pantalla de cada dispositivo, y esto en la mayoría de los casos hace que la aplicación se vea bien, una solución es crear el mismo layout para cada tipo de pantalla.

* Utilizar unidades de medidas escalables por el Sistema Operativo

Esto es tán simple como empezar a hacer las cosas bien desde un primer instante, y nuestra aplicación quedará lista para ser compatible con cualquier pantalla. Se trata de utilizar las siguientes unidades para determinadas situaciones:

Para indicar cualquier tamaño de widgets, o distancia entre ellos, hay que utilizar la unidad “dp” (y no “px” como naturalmente haríamos).
Cuando se indique el tamaño de las fuentes, hay que usar “sp” debido a que esta unidad está vinculada con el tamaño de fuente especificado por el usuario a todo el SO, entonces se adaptaría a las preferencias del usuario.

* Proveer distintos recursos para cada tipo de pantalla.

El Sistema Operativo escalará todos los recursos (como las imágenes) de acuerdo al tipo de pantalla de cada dispositivo para que se vean correctamente. Sin embargo, es conveniente proveer un recurso con el tamaño adecuado para tipo de pantalla.

=¿Cómo testear la compatibilidad?=

Para probar que la aplicación se ve correctamente en distintos dispositivos con distintas características de pantallas, se debe crear un emulador distinto para cada tipo de pantalla que se quiera probar, y luego verificar visualmente todas las actividades de la aplicación.

===Fuente===
* [http://developer.android.com/develop/index.html Sitio web de Android para desarrolladores]

===Ver también===
* [https://docs.google.com/document/d/1foAIFGOm9UsUMl5ebdDEWvrtAAQO0kHHyqvHtwB_N-A/edit Desarrollando Android apps para distintas pantallas (actualizado)]

Spring Data

2012-06-15T15:50:37Z

Barrios.nahuel: /* Comentario adicional */

==Introducción==
La herramienta que encontramos útil para dejar de hacer manualmente las implementaciones de los DAO que suelen ser siempre de la misma manera, fué a través de Spring Data JPA. [http://www.springsource.org/spring-data/jpa|http://www.springsource.org/spring-data/jpa]

Este framework nos permite, siguiendo una serie de normas que nos establece, crear interfaces de DAOs definiendo métodos y NO realizar ninguna implementación. Es decir, dejamos la responsabilidad de la implementación al framework, el cuál hará la implementación en tiempo de corrida.
Para ello, el framework básicamente lo que hace es buscar, dado un paquete que le indicamos por configuración, todas las interfaces que hereden de org.springframework.data.repository.Repository<T, ID extends Serializable> ya sea directa o indirectamente.

[[Archivo:Spring-Data-JPA-Herencia repository.PNG]]

==Configuración==

===Dependencias (Utilizando Maven)===
Para trabajar con Spring Data JPA, solo debemos agregar la dependencia:
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.0.3.RELEASE</version>
</dependency>

Siempre y cuando contemos con una configuración de persistencia que utilice:
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
<property name="jpaDialect">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaDialect" />
</property>
</bean>
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="defaultDataSource" />
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="generateDdl" value="false" />
</bean>
</property>
</bean>

===Configurando el paquete a escanear===

En el applicationContext.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jpa="http://www.springframework.org/schema/data/jpa"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://www.springframework.org/schema/data/jpa http://www.springframework.org/schema/data/jpa/spring-jpa.xsd">
.
.
.

<jpa:repositories base-package="com.th.ctc.dao" />
.
.
.
</beans>

==Implementación==
===El ejemplo fácil===
====Definiendo la interfaz del DAO====
Para este ejemplo sencillo, la interfaz del DAO va a quedar sin métodos definidos explicitamente, pero con todos aquellos que estamos heredando.

import org.springframework.data.repository.CrudRepository;
import com.th.ctc.domain.Cliente;
/**
* Interfaz del DAO para la entidad {@link Cliente}. Esta interfaz NO tiene una
* implementacion concreta dado que al extender de Repository la implementacion
* la hace en runtime Spring Data JPA.
*
* @author Alguien.
*/
public interface ClienteDao extends CrudRepository<Cliente, Long> {
}

====Usando el DAO desde el Service====
Hasta acá llegamos. A partir de ahora no hay mas código vinculado con el DAO más que el uso de los métodos que estamos exponiendo en la interfaz que nosotros mismos creamos. Por lo tanto nuestro Service sería algo como:

/**
* DAO de clientes.
*/
@Autowired
private ClienteDao clienteDao;
@Override
public List<Cliente> buscarTodos() {
return (List<Cliente>) clienteDao.findAll(); //El método findAll() proviene de CrudRepository
}

====Test====
Como no hay una implementación concreta, y de haber, no la hacemos nosotros sino que estamos delegando la responsabilidad al framework, no hacemos tests de la capa DAO, pero si del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA además claro de la lógica propia del Service.

===El ejemplo habitual===

====Definiendo la interfaz del DAO====
Para este ejemplo sencillo, la interfaz del DAO va a quedar sin métodos definidos explicitamente, pero con todos aquellos que estamos heredando.

import org.springframework.data.repository.PagingAndSortingRepository;
import com.th.ctc.domain.Usuario;
/**
* Interfaz del DAO para la entidad {@link Usuario}. Esta interfaz NO tiene una
* implementacion concreta dado que al extender de Repository la implementación
* la hace en runtime Spring Data JPA.
*
* @author Alguien.
*/
public interface UsuarioDao extends PagingAndSortingRepository<Usuario, Long> {
}

====Usando el DAO desde el Service====
Hasta acá llegamos. A partir de ahora no hay mas código vinculado con el DAO más que el uso de los métodos que estamos exponiendo en la interfaz que nosotros mismos creamos. Por lo tanto nuestro Service sería algo como:

/**
* DAO de usuarios.
*/
@Autowired
private UsuarioDao usuarioDao;
@Override
public List<Usuario> buscarTodos() {
// El método findAll(Sort) proviene de PagingAndSortingRepository y con el String "apellido" (es el nombre del
// atributo de clase de la entidad Usuario) estamos indicando que se ordenaran los resultados por ese campo
return (List<Usuario>) usuarioDao.findAll(new Sort("apellido"));
}

====Test====
Como no hay una implementación concreta, y de haber, no la hacemos nosotros sino que estamos delegando la responsabilidad al framework, no hacemos tests de la capa DAO, pero si del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA además claro de la lógica propia del Service.

===El ejemplo dificil===
Supongamos que ahora necesitamos 2 cosas:
Por un lado, recuperar todos los elementos de una entidad, recuperar uno solo en base al ID y etc., y por otro, generar un archivo Excel con información recuperada de una consulta a una base de datos muy específica.
Para lograr esto, aprovechando esta herramienta, necesitamos 2 interfaces del DAO. Una para definir estos métodos tan complejos que necesitamos, y otra para utilizar de la misma manera que en el ejemplo fácil.

¿Pero entonces el Service tiene que utilizar 2 DAOs distintos sobre la misma entidad?

No. Antes que nada, veamos un diagrama de clases para que veamos por qué este es el ejemplo dificil:
[[Media:Ejemplo complejo Spring Data JPA.PNG|Diagrama de clases]]

Es decir, tenemos un Service (TareaServiceImpl) que utiliza un DAO (TareaDao). Nada nuevo hasta acá. Sin embargo, este TareaDao no solo hereda de Repository al heredar de org.springframework.data.repository.PagingAndSortingRepository, sino que también está heredando de una interfaz definida por nosotros (CustomTareaDao).

¿Por qué necesitamos esto?

Bueno, por que si bien podemos definir métodos en la interfaz que hereda de Repository, estos métodos tienen que seguir una nomenclatura específica para que el framework pueda hacer la implementación y, además, porque no podemos definir métodos que no queremos que los implemente Spring Data JPA para implementarlos nosotros.

====Definiendo la interfaz del DAO====

import java.util.Date;
import java.util.List;
import org.springframework.data.domain.Sort;
import org.springframework.data.repository.PagingAndSortingRepository;
import com.th.ctc.domain.Tarea;
/**
* Interfaz el DAO de las {@link Tarea} implementado por Spring Data JPA.
*
* @author Alguien.
*/
public interface TareaDao extends PagingAndSortingRepository<Tarea, Long>, CustomTareaDao {
/**
* Recupera todas las tareas del usuario que le pasamos, para la fecha dada.
*
* @author Alguien.
* @param idUsuario
* {@link Long} con el ID del usuario duenio de la tarea.
* @param fechaDesde
* {@link Date} la fecha desde la cual se buscara.
* @param fechaHasta
* {@link Date} la fecha hasta la cual se buscara.
* @param sort
* {@link Sort} de Spring Data JPA utilizado para ordenar los
* resultados segun cierto criterio.
* @return {@link List<Tarea>} Las tareas encontradas.
*/
List<Tarea> findByUsuarioIdAndFechaBetween(Long idUsuario, Date fechaDesde, Date fechaHasta, Sort sort);
}

Como vemos, estamos definiendo un método '''findByUsuarioIdAndFechaBetween''' que sigue la nomenclatura del framework para recuperar un listado de tareas en base al Id del Usuario que le pasamos, entre un rango de fechas dado, y que al definir con esta nomenclatura hacemos que la implementación quede a cargo del framework.

====Usando el DAO desde el Service====
Ahora, nuestro Service cuenta con un DAO que tiene:
* Métodos definidos en él;
* Métodos provistos por PagingAndSortingRepository;
* Métodos provistos por CustomTareaDao.

¿Y las implementaciones?

Las implementaciones de los métodos definidos en TareaDao y los heredados de PagingAndSortingRepository, nos las va a proveer el framework. Y para la interfaz CustomTareaDao nosotros debemos definir nuestro DaoImpl común y corriente.

====Test====
A la hora de testear, debemos tener un test (en nuestro caso es TareaDaoComponenteTest) que testee de la interfaz DAO que exponemos (es decír, TareaDao):
* Los métodos definidos manualmente en el DAO siguiendo la nomenclatura específica del framework. Ej: List<Tarea> findByUsuarioIdAndFechaBetween(Long idUsuario, Date fechaDesde, Date fechaHasta, Sort sort);
* Los métodos definidos en la interfaz creada para los métodos específicos (CustomTareaDao). Ej: ScrollableResults buscarResumenHoras(FiltroResumenHorasDto filtro);

===Test===
Como estamos delegando la responsabilidad de la implementación del DAO en un framework, y como ni siquiera sabemos como es la implementación dado que se produce en runtime, decidimos no testear aquellos métodos ya tenemos definidos al heredar de alguna de las interfaces que nos provee la herramienta.
Sin embargo, sí decidimos testear la capa del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA, además claro de la lógica propia del Service.

==Mas==

===SELECT DISTINCT===

====Situación a resolver====
Necesitamos recuperar todos los clientes, tal que alguno de los servicios de los clientes cumpla con una condición determinada.

====Primera solución====
Creamos un método:
List<Cliente> findByServiciosEstado(EstadosServicios estado);

====Problema====
El método traía repetidos los clientes por cada uno de sus servicios que cumplían con la condición.

=====Contexto=====
* Spring Data JPA, version 1.0.3.RELEASE.

=====Solución=====
Al método le agregamos la keyword Distinct delante del By:
List<Cliente> findDistinctByServiciosEstado(EstadosServicios estado);

=====Comentario adicional=====
El problema de esto es que la keyword no está en la [http://static.springsource.org/spring-data/data-jpa/docs/current/reference/html/#repository-query-keywords| documentación oficial de Spring Data JPA].
Sin embargo, encontramos una [https://jira.springsource.org/browse/DATAJPA-174?page=com.atlassian.streams.streams-jira-plugin:activity-stream-issue-tab| issue en el Jira de Spring Data JPA] sobre el tema.

Por último, [http://static.springsource.org/spring-data/data-jpa/docs/1.0.0.RELEASE/changelog.txt | en el changelog de la versión] se indica que está soportado.

===Proyecto de ejemplo===
Pueden descargarse un proyecto de ejemplo haciendo un checkout mediante un cliente de SVN de:
http://dosideas-aplicaciones-modelo.googlecode.com/svn/trunk/spring-data/trunk

Spring Data

2012-06-15T15:48:10Z

Barrios.nahuel: /* Mas */

==Introducción==
La herramienta que encontramos útil para dejar de hacer manualmente las implementaciones de los DAO que suelen ser siempre de la misma manera, fué a través de Spring Data JPA. [http://www.springsource.org/spring-data/jpa|http://www.springsource.org/spring-data/jpa]

Este framework nos permite, siguiendo una serie de normas que nos establece, crear interfaces de DAOs definiendo métodos y NO realizar ninguna implementación. Es decir, dejamos la responsabilidad de la implementación al framework, el cuál hará la implementación en tiempo de corrida.
Para ello, el framework básicamente lo que hace es buscar, dado un paquete que le indicamos por configuración, todas las interfaces que hereden de org.springframework.data.repository.Repository<T, ID extends Serializable> ya sea directa o indirectamente.

[[Archivo:Spring-Data-JPA-Herencia repository.PNG]]

==Configuración==

===Dependencias (Utilizando Maven)===
Para trabajar con Spring Data JPA, solo debemos agregar la dependencia:
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.0.3.RELEASE</version>
</dependency>

Siempre y cuando contemos con una configuración de persistencia que utilice:
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
<property name="jpaDialect">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaDialect" />
</property>
</bean>
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="defaultDataSource" />
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="generateDdl" value="false" />
</bean>
</property>
</bean>

===Configurando el paquete a escanear===

En el applicationContext.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jpa="http://www.springframework.org/schema/data/jpa"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://www.springframework.org/schema/data/jpa http://www.springframework.org/schema/data/jpa/spring-jpa.xsd">
.
.
.

<jpa:repositories base-package="com.th.ctc.dao" />
.
.
.
</beans>

==Implementación==
===El ejemplo fácil===
====Definiendo la interfaz del DAO====
Para este ejemplo sencillo, la interfaz del DAO va a quedar sin métodos definidos explicitamente, pero con todos aquellos que estamos heredando.

import org.springframework.data.repository.CrudRepository;
import com.th.ctc.domain.Cliente;
/**
* Interfaz del DAO para la entidad {@link Cliente}. Esta interfaz NO tiene una
* implementacion concreta dado que al extender de Repository la implementacion
* la hace en runtime Spring Data JPA.
*
* @author Alguien.
*/
public interface ClienteDao extends CrudRepository<Cliente, Long> {
}

====Usando el DAO desde el Service====
Hasta acá llegamos. A partir de ahora no hay mas código vinculado con el DAO más que el uso de los métodos que estamos exponiendo en la interfaz que nosotros mismos creamos. Por lo tanto nuestro Service sería algo como:

/**
* DAO de clientes.
*/
@Autowired
private ClienteDao clienteDao;
@Override
public List<Cliente> buscarTodos() {
return (List<Cliente>) clienteDao.findAll(); //El método findAll() proviene de CrudRepository
}

====Test====
Como no hay una implementación concreta, y de haber, no la hacemos nosotros sino que estamos delegando la responsabilidad al framework, no hacemos tests de la capa DAO, pero si del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA además claro de la lógica propia del Service.

===El ejemplo habitual===

====Definiendo la interfaz del DAO====
Para este ejemplo sencillo, la interfaz del DAO va a quedar sin métodos definidos explicitamente, pero con todos aquellos que estamos heredando.

import org.springframework.data.repository.PagingAndSortingRepository;
import com.th.ctc.domain.Usuario;
/**
* Interfaz del DAO para la entidad {@link Usuario}. Esta interfaz NO tiene una
* implementacion concreta dado que al extender de Repository la implementación
* la hace en runtime Spring Data JPA.
*
* @author Alguien.
*/
public interface UsuarioDao extends PagingAndSortingRepository<Usuario, Long> {
}

====Usando el DAO desde el Service====
Hasta acá llegamos. A partir de ahora no hay mas código vinculado con el DAO más que el uso de los métodos que estamos exponiendo en la interfaz que nosotros mismos creamos. Por lo tanto nuestro Service sería algo como:

/**
* DAO de usuarios.
*/
@Autowired
private UsuarioDao usuarioDao;
@Override
public List<Usuario> buscarTodos() {
// El método findAll(Sort) proviene de PagingAndSortingRepository y con el String "apellido" (es el nombre del
// atributo de clase de la entidad Usuario) estamos indicando que se ordenaran los resultados por ese campo
return (List<Usuario>) usuarioDao.findAll(new Sort("apellido"));
}

====Test====
Como no hay una implementación concreta, y de haber, no la hacemos nosotros sino que estamos delegando la responsabilidad al framework, no hacemos tests de la capa DAO, pero si del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA además claro de la lógica propia del Service.

===El ejemplo dificil===
Supongamos que ahora necesitamos 2 cosas:
Por un lado, recuperar todos los elementos de una entidad, recuperar uno solo en base al ID y etc., y por otro, generar un archivo Excel con información recuperada de una consulta a una base de datos muy específica.
Para lograr esto, aprovechando esta herramienta, necesitamos 2 interfaces del DAO. Una para definir estos métodos tan complejos que necesitamos, y otra para utilizar de la misma manera que en el ejemplo fácil.

¿Pero entonces el Service tiene que utilizar 2 DAOs distintos sobre la misma entidad?

No. Antes que nada, veamos un diagrama de clases para que veamos por qué este es el ejemplo dificil:
[[Media:Ejemplo complejo Spring Data JPA.PNG|Diagrama de clases]]

Es decir, tenemos un Service (TareaServiceImpl) que utiliza un DAO (TareaDao). Nada nuevo hasta acá. Sin embargo, este TareaDao no solo hereda de Repository al heredar de org.springframework.data.repository.PagingAndSortingRepository, sino que también está heredando de una interfaz definida por nosotros (CustomTareaDao).

¿Por qué necesitamos esto?

Bueno, por que si bien podemos definir métodos en la interfaz que hereda de Repository, estos métodos tienen que seguir una nomenclatura específica para que el framework pueda hacer la implementación y, además, porque no podemos definir métodos que no queremos que los implemente Spring Data JPA para implementarlos nosotros.

====Definiendo la interfaz del DAO====

import java.util.Date;
import java.util.List;
import org.springframework.data.domain.Sort;
import org.springframework.data.repository.PagingAndSortingRepository;
import com.th.ctc.domain.Tarea;
/**
* Interfaz el DAO de las {@link Tarea} implementado por Spring Data JPA.
*
* @author Alguien.
*/
public interface TareaDao extends PagingAndSortingRepository<Tarea, Long>, CustomTareaDao {
/**
* Recupera todas las tareas del usuario que le pasamos, para la fecha dada.
*
* @author Alguien.
* @param idUsuario
* {@link Long} con el ID del usuario duenio de la tarea.
* @param fechaDesde
* {@link Date} la fecha desde la cual se buscara.
* @param fechaHasta
* {@link Date} la fecha hasta la cual se buscara.
* @param sort
* {@link Sort} de Spring Data JPA utilizado para ordenar los
* resultados segun cierto criterio.
* @return {@link List<Tarea>} Las tareas encontradas.
*/
List<Tarea> findByUsuarioIdAndFechaBetween(Long idUsuario, Date fechaDesde, Date fechaHasta, Sort sort);
}

Como vemos, estamos definiendo un método '''findByUsuarioIdAndFechaBetween''' que sigue la nomenclatura del framework para recuperar un listado de tareas en base al Id del Usuario que le pasamos, entre un rango de fechas dado, y que al definir con esta nomenclatura hacemos que la implementación quede a cargo del framework.

====Usando el DAO desde el Service====
Ahora, nuestro Service cuenta con un DAO que tiene:
* Métodos definidos en él;
* Métodos provistos por PagingAndSortingRepository;
* Métodos provistos por CustomTareaDao.

¿Y las implementaciones?

Las implementaciones de los métodos definidos en TareaDao y los heredados de PagingAndSortingRepository, nos las va a proveer el framework. Y para la interfaz CustomTareaDao nosotros debemos definir nuestro DaoImpl común y corriente.

====Test====
A la hora de testear, debemos tener un test (en nuestro caso es TareaDaoComponenteTest) que testee de la interfaz DAO que exponemos (es decír, TareaDao):
* Los métodos definidos manualmente en el DAO siguiendo la nomenclatura específica del framework. Ej: List<Tarea> findByUsuarioIdAndFechaBetween(Long idUsuario, Date fechaDesde, Date fechaHasta, Sort sort);
* Los métodos definidos en la interfaz creada para los métodos específicos (CustomTareaDao). Ej: ScrollableResults buscarResumenHoras(FiltroResumenHorasDto filtro);

===Test===
Como estamos delegando la responsabilidad de la implementación del DAO en un framework, y como ni siquiera sabemos como es la implementación dado que se produce en runtime, decidimos no testear aquellos métodos ya tenemos definidos al heredar de alguna de las interfaces que nos provee la herramienta.
Sin embargo, sí decidimos testear la capa del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA, además claro de la lógica propia del Service.

==Mas==

===SELECT DISTINCT===

====Situación a resolver====
Necesitamos recuperar todos los clientes, tal que alguno de los servicios de los clientes cumpla con una condición determinada.

====Primera solución====
Creamos un método:
List<Cliente> findByServiciosEstado(EstadosServicios estado);

====Problema====
El método traía repetidos los clientes por cada uno de sus servicios que cumplían con la condición.

=====Contexto=====
* Spring Data JPA, version 1.0.3.RELEASE.

=====Solución=====
Al método le agregamos la keyword Distinct delante del By:
List<Cliente> findDistinctByServiciosEstado(EstadosServicios estado);

=====Comentario adicional=====
El problema de esto es que la keyword no está en la [http://static.springsource.org/spring-data/data-jpa/docs/current/reference/html/#repository-query-keywords| documentación oficial de Spring Data JPA].
Sin embargo, encontramos una [https://jira.springsource.org/browse/DATAJPA-174?page=com.atlassian.streams.streams-jira-plugin:activity-stream-issue-tab| issue en el Jira de Spring Data JPA] sobre el tema.

Por último, [http://static.springsource.org/spring-data/data-jpa/docs/1.0.0.RELEASE/changelog.txt| en el changelog de la versión] se indica que está soportado.

===Proyecto de ejemplo===
Pueden descargarse un proyecto de ejemplo haciendo un checkout mediante un cliente de SVN de:
http://dosideas-aplicaciones-modelo.googlecode.com/svn/trunk/spring-data/trunk

Spring Data

2012-05-08T15:22:56Z

Barrios.nahuel:

==Introducción==
La herramienta que encontramos útil para dejar de hacer manualmente las implementaciones de los DAO que suelen ser siempre de la misma manera, fué a través de Spring Data JPA. [http://www.springsource.org/spring-data/jpa|http://www.springsource.org/spring-data/jpa]

Este framework nos permite, siguiendo una serie de normas que nos establece, crear interfaces de DAOs definiendo métodos y NO realizar ninguna implementación. Es decir, dejamos la responsabilidad de la implementación al framework, el cuál hará la implementación en tiempo de corrida.
Para ello, el framework básicamente lo que hace es buscar, dado un paquete que le indicamos por configuración, todas las interfaces que hereden de org.springframework.data.repository.Repository<T, ID extends Serializable> ya sea directa o indirectamente.

[[Archivo:Spring-Data-JPA-Herencia repository.PNG]]

==Configuración==

===Dependencias (Utilizando Maven)===
Para trabajar con Spring Data JPA, solo debemos agregar la dependencia:
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.0.3.RELEASE</version>
</dependency>

Siempre y cuando contemos con una configuración de persistencia que utilice:
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
<property name="jpaDialect">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaDialect" />
</property>
</bean>
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="defaultDataSource" />
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="generateDdl" value="false" />
</bean>
</property>
</bean>

===Configurando el paquete a escanear===

En el applicationContext.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jpa="http://www.springframework.org/schema/data/jpa"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://www.springframework.org/schema/data/jpa http://www.springframework.org/schema/data/jpa/spring-jpa.xsd">
.
.
.

<jpa:repositories base-package="com.th.ctc.dao" />
.
.
.
</beans>

==Implementación==
===El ejemplo fácil===
====Definiendo la interfaz del DAO====
Para este ejemplo sencillo, la interfaz del DAO va a quedar sin métodos definidos explicitamente, pero con todos aquellos que estamos heredando.

import org.springframework.data.repository.CrudRepository;
import com.th.ctc.domain.Cliente;
/**
* Interfaz del DAO para la entidad {@link Cliente}. Esta interfaz NO tiene una
* implementacion concreta dado que al extender de Repository la implementacion
* la hace en runtime Spring Data JPA.
*
* @author Alguien.
*/
public interface ClienteDao extends CrudRepository<Cliente, Long> {
}

====Usando el DAO desde el Service====
Hasta acá llegamos. A partir de ahora no hay mas código vinculado con el DAO más que el uso de los métodos que estamos exponiendo en la interfaz que nosotros mismos creamos. Por lo tanto nuestro Service sería algo como:

/**
* DAO de clientes.
*/
@Autowired
private ClienteDao clienteDao;
@Override
public List<Cliente> buscarTodos() {
return (List<Cliente>) clienteDao.findAll(); //El método findAll() proviene de CrudRepository
}

====Test====
Como no hay una implementación concreta, y de haber, no la hacemos nosotros sino que estamos delegando la responsabilidad al framework, no hacemos tests de la capa DAO, pero si del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA además claro de la lógica propia del Service.

===El ejemplo habitual===

====Definiendo la interfaz del DAO====
Para este ejemplo sencillo, la interfaz del DAO va a quedar sin métodos definidos explicitamente, pero con todos aquellos que estamos heredando.

import org.springframework.data.repository.PagingAndSortingRepository;
import com.th.ctc.domain.Usuario;
/**
* Interfaz del DAO para la entidad {@link Usuario}. Esta interfaz NO tiene una
* implementacion concreta dado que al extender de Repository la implementación
* la hace en runtime Spring Data JPA.
*
* @author Alguien.
*/
public interface UsuarioDao extends PagingAndSortingRepository<Usuario, Long> {
}

====Usando el DAO desde el Service====
Hasta acá llegamos. A partir de ahora no hay mas código vinculado con el DAO más que el uso de los métodos que estamos exponiendo en la interfaz que nosotros mismos creamos. Por lo tanto nuestro Service sería algo como:

/**
* DAO de usuarios.
*/
@Autowired
private UsuarioDao usuarioDao;
@Override
public List<Usuario> buscarTodos() {
// El método findAll(Sort) proviene de PagingAndSortingRepository y con el String "apellido" (es el nombre del
// atributo de clase de la entidad Usuario) estamos indicando que se ordenaran los resultados por ese campo
return (List<Usuario>) usuarioDao.findAll(new Sort("apellido"));
}

====Test====
Como no hay una implementación concreta, y de haber, no la hacemos nosotros sino que estamos delegando la responsabilidad al framework, no hacemos tests de la capa DAO, pero si del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA además claro de la lógica propia del Service.

===El ejemplo dificil===
Supongamos que ahora necesitamos 2 cosas:
Por un lado, recuperar todos los elementos de una entidad, recuperar uno solo en base al ID y etc., y por otro, generar un archivo Excel con información recuperada de una consulta a una base de datos muy específica.
Para lograr esto, aprovechando esta herramienta, necesitamos 2 interfaces del DAO. Una para definir estos métodos tan complejos que necesitamos, y otra para utilizar de la misma manera que en el ejemplo fácil.

¿Pero entonces el Service tiene que utilizar 2 DAOs distintos sobre la misma entidad?

No. Antes que nada, veamos un diagrama de clases para que veamos por qué este es el ejemplo dificil:
[[Media:Ejemplo complejo Spring Data JPA.PNG|Diagrama de clases]]

Es decir, tenemos un Service (TareaServiceImpl) que utiliza un DAO (TareaDao). Nada nuevo hasta acá. Sin embargo, este TareaDao no solo hereda de Repository al heredar de org.springframework.data.repository.PagingAndSortingRepository, sino que también está heredando de una interfaz definida por nosotros (CustomTareaDao).

¿Por qué necesitamos esto?

Bueno, por que si bien podemos definir métodos en la interfaz que hereda de Repository, estos métodos tienen que seguir una nomenclatura específica para que el framework pueda hacer la implementación y, además, porque no podemos definir métodos que no queremos que los implemente Spring Data JPA para implementarlos nosotros.

====Definiendo la interfaz del DAO====

import java.util.Date;
import java.util.List;
import org.springframework.data.domain.Sort;
import org.springframework.data.repository.PagingAndSortingRepository;
import com.th.ctc.domain.Tarea;
/**
* Interfaz el DAO de las {@link Tarea} implementado por Spring Data JPA.
*
* @author Alguien.
*/
public interface TareaDao extends PagingAndSortingRepository<Tarea, Long>, CustomTareaDao {
/**
* Recupera todas las tareas del usuario que le pasamos, para la fecha dada.
*
* @author Alguien.
* @param idUsuario
* {@link Long} con el ID del usuario duenio de la tarea.
* @param fechaDesde
* {@link Date} la fecha desde la cual se buscara.
* @param fechaHasta
* {@link Date} la fecha hasta la cual se buscara.
* @param sort
* {@link Sort} de Spring Data JPA utilizado para ordenar los
* resultados segun cierto criterio.
* @return {@link List<Tarea>} Las tareas encontradas.
*/
List<Tarea> findByUsuarioIdAndFechaBetween(Long idUsuario, Date fechaDesde, Date fechaHasta, Sort sort);
}

Como vemos, estamos definiendo un método '''findByUsuarioIdAndFechaBetween''' que sigue la nomenclatura del framework para recuperar un listado de tareas en base al Id del Usuario que le pasamos, entre un rango de fechas dado, y que al definir con esta nomenclatura hacemos que la implementación quede a cargo del framework.

====Usando el DAO desde el Service====
Ahora, nuestro Service cuenta con un DAO que tiene:
* Métodos definidos en él;
* Métodos provistos por PagingAndSortingRepository;
* Métodos provistos por CustomTareaDao.

¿Y las implementaciones?

Las implementaciones de los métodos definidos en TareaDao y los heredados de PagingAndSortingRepository, nos las va a proveer el framework. Y para la interfaz CustomTareaDao nosotros debemos definir nuestro DaoImpl común y corriente.

====Test====
A la hora de testear, debemos tener un test (en nuestro caso es TareaDaoComponenteTest) que testee de la interfaz DAO que exponemos (es decír, TareaDao):
* Los métodos definidos manualmente en el DAO siguiendo la nomenclatura específica del framework. Ej: List<Tarea> findByUsuarioIdAndFechaBetween(Long idUsuario, Date fechaDesde, Date fechaHasta, Sort sort);
* Los métodos definidos en la interfaz creada para los métodos específicos (CustomTareaDao). Ej: ScrollableResults buscarResumenHoras(FiltroResumenHorasDto filtro);

===Test===
Como estamos delegando la responsabilidad de la implementación del DAO en un framework, y como ni siquiera sabemos como es la implementación dado que se produce en runtime, decidimos no testear aquellos métodos ya tenemos definidos al heredar de alguna de las interfaces que nos provee la herramienta.
Sin embargo, sí decidimos testear la capa del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA, además claro de la lógica propia del Service.

==Mas==
Pueden descargarse un proyecto de ejemplo haciendo un checkout mediante un cliente de SVN de:
http://dosideas-aplicaciones-modelo.googlecode.com/svn/trunk/spring-data/trunk

Spring Data

2012-05-08T15:16:40Z

Barrios.nahuel: /* El ejemplo dificil */

Spring Data

2012-05-08T15:10:40Z

Barrios.nahuel: /* El ejemplo dificil */

==Introducción==
La herramienta que encontramos útil para dejar de hacer manualmente las implementaciones de los DAO que suelen ser siempre de la misma manera, fué a través de Spring Data JPA. [http://www.springsource.org/spring-data/jpa|http://www.springsource.org/spring-data/jpa]

Este framework nos permite, siguiendo una serie de normas que nos establece, crear interfaces de DAOs definiendo métodos y NO realizar ninguna implementación. Es decir, dejamos la responsabilidad de la implementación al framework, el cuál hará la implementación en tiempo de corrida.
Para ello, el framework básicamente lo que hace es buscar, dado un paquete que le indicamos por configuración, todas las interfaces que hereden de org.springframework.data.repository.Repository<T, ID extends Serializable> ya sea directa o indirectamente.

[[Archivo:Spring-Data-JPA-Herencia repository.PNG]]

==Configuración==

===Dependencias (Utilizando Maven)===
Para trabajar con Spring Data JPA, solo debemos agregar la dependencia:
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.0.3.RELEASE</version>
</dependency>

Siempre y cuando contemos con una configuración de persistencia que utilice:
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
<property name="jpaDialect">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaDialect" />
</property>
</bean>
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="defaultDataSource" />
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="generateDdl" value="false" />
</bean>
</property>
</bean>

===Configurando el paquete a escanear===

En el applicationContext.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jpa="http://www.springframework.org/schema/data/jpa"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://www.springframework.org/schema/data/jpa http://www.springframework.org/schema/data/jpa/spring-jpa.xsd">
.
.
.

<jpa:repositories base-package="com.th.ctc.dao" />
.
.
.
</beans>

==Implementación==
===El ejemplo fácil===
====Definiendo la interfaz del DAO====
Para este ejemplo sencillo, la interfaz del DAO va a quedar sin métodos definidos explicitamente, pero con todos aquellos que estamos heredando.

import org.springframework.data.repository.CrudRepository;
import com.th.ctc.domain.Cliente;
/**
* Interfaz del DAO para la entidad {@link Cliente}. Esta interfaz NO tiene una
* implementacion concreta dado que al extender de Repository la implementacion
* la hace en runtime Spring Data JPA.
*
* @author Alguien.
*/
public interface ClienteDao extends CrudRepository<Cliente, Long> {
}

====Usando el DAO desde el Service====
Hasta acá llegamos. A partir de ahora no hay mas código vinculado con el DAO más que el uso de los métodos que estamos exponiendo en la interfaz que nosotros mismos creamos. Por lo tanto nuestro Service sería algo como:

/**
* DAO de clientes.
*/
@Autowired
private ClienteDao clienteDao;
@Override
public List<Cliente> buscarTodos() {
return (List<Cliente>) clienteDao.findAll(); //El método findAll() proviene de CrudRepository
}

====Test====
Como no hay una implementación concreta, y de haber, no la hacemos nosotros sino que estamos delegando la responsabilidad al framework, no hacemos tests de la capa DAO, pero si del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA además claro de la lógica propia del Service.

===El ejemplo habitual===

====Definiendo la interfaz del DAO====
Para este ejemplo sencillo, la interfaz del DAO va a quedar sin métodos definidos explicitamente, pero con todos aquellos que estamos heredando.

import org.springframework.data.repository.PagingAndSortingRepository;
import com.th.ctc.domain.Usuario;
/**
* Interfaz del DAO para la entidad {@link Usuario}. Esta interfaz NO tiene una
* implementacion concreta dado que al extender de Repository la implementación
* la hace en runtime Spring Data JPA.
*
* @author Alguien.
*/
public interface UsuarioDao extends PagingAndSortingRepository<Usuario, Long> {
}

====Usando el DAO desde el Service====
Hasta acá llegamos. A partir de ahora no hay mas código vinculado con el DAO más que el uso de los métodos que estamos exponiendo en la interfaz que nosotros mismos creamos. Por lo tanto nuestro Service sería algo como:

/**
* DAO de usuarios.
*/
@Autowired
private UsuarioDao usuarioDao;
@Override
public List<Usuario> buscarTodos() {
// El método findAll(Sort) proviene de PagingAndSortingRepository y con el String "apellido" (es el nombre del
// atributo de clase de la entidad Usuario) estamos indicando que se ordenaran los resultados por ese campo
return (List<Usuario>) usuarioDao.findAll(new Sort("apellido"));
}

====Test====
Como no hay una implementación concreta, y de haber, no la hacemos nosotros sino que estamos delegando la responsabilidad al framework, no hacemos tests de la capa DAO, pero si del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA además claro de la lógica propia del Service.

===El ejemplo dificil===
Supongamos que ahora necesitamos 2 cosas:
Por un lado, recuperar todos los elementos de una entidad, recuperar uno solo en base al ID y etc., y por otro, generar un archivo Excel con información recuperada de una consulta a una base de datos muy específica.
Para lograr esto, aprovechando esta herramienta, necesitamos 2 interfaces del DAO. Una para definir estos métodos tan complejos que necesitamos, y otra para utilizar de la misma manera que en el ejemplo fácil.

¿Pero entonces el Service tiene que utilizar 2 DAOs distintos sobre la misma entidad?

No. Antes que nada, veamos un diagrama de clases para que veamos por qué este es el ejemplo dificil:
[[Archivo:Ejemplo complejo Spring Data JPA.PNG|thumb|left|hola]]

Es decir, tenemos un Service (TareaServiceImpl) que utiliza un DAO (TareaDao). Nada nuevo hasta acá. Sin embargo, este TareaDao no solo hereda de Repository al heredar de org.springframework.data.repository.PagingAndSortingRepository, sino que también está heredando de una interfaz definida por nosotros (CustomTareaDao).

¿Por qué necesitamos esto?

Bueno, por que si bien podemos definir métodos en la interfaz que hereda de Repository, estos métodos tienen que seguir una nomenclatura específica para que el framework pueda hacer la implementación y, además, porque no podemos definir métodos que no queremos que los implemente Spring Data JPA para implementarlos nosotros.

====Definiendo la interfaz del DAO====

import java.util.Date;
import java.util.List;
import org.springframework.data.domain.Sort;
import org.springframework.data.repository.PagingAndSortingRepository;
import com.th.ctc.domain.Tarea;
/**
* Interfaz el DAO de las {@link Tarea} implementado por Spring Data JPA.
*
* @author Alguien.
*/
public interface TareaDao extends PagingAndSortingRepository<Tarea, Long>, CustomTareaDao {
/**
* Recupera todas las tareas del usuario que le pasamos, para la fecha dada.
*
* @author Alguien.
* @param idUsuario
* {@link Long} con el ID del usuario duenio de la tarea.
* @param fechaDesde
* {@link Date} la fecha desde la cual se buscara.
* @param fechaHasta
* {@link Date} la fecha hasta la cual se buscara.
* @param sort
* {@link Sort} de Spring Data JPA utilizado para ordenar los
* resultados segun cierto criterio.
* @return {@link List<Tarea>} Las tareas encontradas.
*/
List<Tarea> findByUsuarioIdAndFechaBetween(Long idUsuario, Date fechaDesde, Date fechaHasta, Sort sort);
}

Como vemos, estamos definiendo un método '''findByUsuarioIdAndFechaBetween''' que sigue la nomenclatura del framework para recuperar un listado de tareas en base al Id del Usuario que le pasamos, entre un rango de fechas dado, y que al definir con esta nomenclatura hacemos que la implementación quede a cargo del framework.

====Usando el DAO desde el Service====
Ahora, nuestro Service cuenta con un DAO que tiene:
* Métodos definidos en él;
* Métodos provistos por PagingAndSortingRepository;
* Métodos provistos por CustomTareaDao.

¿Y las implementaciones?

Las implementaciones de los métodos definidos en TareaDao y los heredados de PagingAndSortingRepository, nos las va a proveer el framework. Y para la interfaz CustomTareaDao nosotros debemos definir nuestro DaoImpl común y corriente.

====Test====
A la hora de testear, debemos tener un test (en nuestro caso es TareaDaoComponenteTest) que testee de la interfaz DAO que exponemos (es decír, TareaDao):
* Los métodos definidos manualmente en el DAO siguiendo la nomenclatura específica del framework. Ej: List<Tarea> findByUsuarioIdAndFechaBetween(Long idUsuario, Date fechaDesde, Date fechaHasta, Sort sort);
* Los métodos definidos en la interfaz creada para los métodos específicos (CustomTareaDao). Ej: ScrollableResults buscarResumenHoras(FiltroResumenHorasDto filtro);

===Test===
Como estamos delegando la responsabilidad de la implementación del DAO en un framework, y como ni siquiera sabemos como es la implementación dado que se produce en runtime, decidimos no testear aquellos métodos ya tenemos definidos al heredar de alguna de las interfaces que nos provee la herramienta.
Sin embargo, sí decidimos testear la capa del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA, además claro de la lógica propia del Service.

Spring Data

2012-05-08T15:07:24Z

Barrios.nahuel: /* El ejemplo dificil */

==Introducción==
La herramienta que encontramos útil para dejar de hacer manualmente las implementaciones de los DAO que suelen ser siempre de la misma manera, fué a través de Spring Data JPA. [http://www.springsource.org/spring-data/jpa|http://www.springsource.org/spring-data/jpa]

Este framework nos permite, siguiendo una serie de normas que nos establece, crear interfaces de DAOs definiendo métodos y NO realizar ninguna implementación. Es decir, dejamos la responsabilidad de la implementación al framework, el cuál hará la implementación en tiempo de corrida.
Para ello, el framework básicamente lo que hace es buscar, dado un paquete que le indicamos por configuración, todas las interfaces que hereden de org.springframework.data.repository.Repository<T, ID extends Serializable> ya sea directa o indirectamente.

[[Archivo:Spring-Data-JPA-Herencia repository.PNG]]

==Configuración==

===Dependencias (Utilizando Maven)===
Para trabajar con Spring Data JPA, solo debemos agregar la dependencia:
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.0.3.RELEASE</version>
</dependency>

Siempre y cuando contemos con una configuración de persistencia que utilice:
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
<property name="jpaDialect">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaDialect" />
</property>
</bean>
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="defaultDataSource" />
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="generateDdl" value="false" />
</bean>
</property>
</bean>

===Configurando el paquete a escanear===

En el applicationContext.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jpa="http://www.springframework.org/schema/data/jpa"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://www.springframework.org/schema/data/jpa http://www.springframework.org/schema/data/jpa/spring-jpa.xsd">
.
.
.

<jpa:repositories base-package="com.th.ctc.dao" />
.
.
.
</beans>

==Implementación==
===El ejemplo fácil===
====Definiendo la interfaz del DAO====
Para este ejemplo sencillo, la interfaz del DAO va a quedar sin métodos definidos explicitamente, pero con todos aquellos que estamos heredando.

import org.springframework.data.repository.CrudRepository;
import com.th.ctc.domain.Cliente;
/**
* Interfaz del DAO para la entidad {@link Cliente}. Esta interfaz NO tiene una
* implementacion concreta dado que al extender de Repository la implementacion
* la hace en runtime Spring Data JPA.
*
* @author Alguien.
*/
public interface ClienteDao extends CrudRepository<Cliente, Long> {
}

====Usando el DAO desde el Service====
Hasta acá llegamos. A partir de ahora no hay mas código vinculado con el DAO más que el uso de los métodos que estamos exponiendo en la interfaz que nosotros mismos creamos. Por lo tanto nuestro Service sería algo como:

/**
* DAO de clientes.
*/
@Autowired
private ClienteDao clienteDao;
@Override
public List<Cliente> buscarTodos() {
return (List<Cliente>) clienteDao.findAll(); //El método findAll() proviene de CrudRepository
}

====Test====
Como no hay una implementación concreta, y de haber, no la hacemos nosotros sino que estamos delegando la responsabilidad al framework, no hacemos tests de la capa DAO, pero si del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA además claro de la lógica propia del Service.

===El ejemplo habitual===

====Definiendo la interfaz del DAO====
Para este ejemplo sencillo, la interfaz del DAO va a quedar sin métodos definidos explicitamente, pero con todos aquellos que estamos heredando.

import org.springframework.data.repository.PagingAndSortingRepository;
import com.th.ctc.domain.Usuario;
/**
* Interfaz del DAO para la entidad {@link Usuario}. Esta interfaz NO tiene una
* implementacion concreta dado que al extender de Repository la implementación
* la hace en runtime Spring Data JPA.
*
* @author Alguien.
*/
public interface UsuarioDao extends PagingAndSortingRepository<Usuario, Long> {
}

====Usando el DAO desde el Service====
Hasta acá llegamos. A partir de ahora no hay mas código vinculado con el DAO más que el uso de los métodos que estamos exponiendo en la interfaz que nosotros mismos creamos. Por lo tanto nuestro Service sería algo como:

/**
* DAO de usuarios.
*/
@Autowired
private UsuarioDao usuarioDao;
@Override
public List<Usuario> buscarTodos() {
// El método findAll(Sort) proviene de PagingAndSortingRepository y con el String "apellido" (es el nombre del
// atributo de clase de la entidad Usuario) estamos indicando que se ordenaran los resultados por ese campo
return (List<Usuario>) usuarioDao.findAll(new Sort("apellido"));
}

====Test====
Como no hay una implementación concreta, y de haber, no la hacemos nosotros sino que estamos delegando la responsabilidad al framework, no hacemos tests de la capa DAO, pero si del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA además claro de la lógica propia del Service.

===El ejemplo dificil===
Supongamos que ahora necesitamos 2 cosas:
Por un lado, recuperar todos los elementos de una entidad, recuperar uno solo en base al ID y etc., y por otro, generar un archivo Excel con información recuperada de una consulta a una base de datos muy específica.
Para lograr esto, aprovechando esta herramienta, necesitamos 2 interfaces del DAO. Una para definir estos métodos tan complejos que necesitamos, y otra para utilizar de la misma manera que en el ejemplo fácil.

¿Pero entonces el Service tiene que utilizar 2 DAOs distintos sobre la misma entidad?

No. Antes que nada, veamos un diagrama de clases para que veamos por qué este es el ejemplo dificil:
[[Archivo:Ejemplo complejo Spring Data JPA.PNG|601px]]

Es decir, tenemos un Service (TareaServiceImpl) que utiliza un DAO (TareaDao). Nada nuevo hasta acá. Sin embargo, este TareaDao no solo hereda de Repository al heredar de org.springframework.data.repository.PagingAndSortingRepository, sino que también está heredando de una interfaz definida por nosotros (CustomTareaDao).

¿Por qué necesitamos esto?

Bueno, por que si bien podemos definir métodos en la interfaz que hereda de Repository, estos métodos tienen que seguir una nomenclatura específica para que el framework pueda hacer la implementación y, además, porque no podemos definir métodos que no queremos que los implemente Spring Data JPA para implementarlos nosotros.

====Definiendo la interfaz del DAO====

import java.util.Date;
import java.util.List;
import org.springframework.data.domain.Sort;
import org.springframework.data.repository.PagingAndSortingRepository;
import com.th.ctc.domain.Tarea;
/**
* Interfaz el DAO de las {@link Tarea} implementado por Spring Data JPA.
*
* @author Alguien.
*/
public interface TareaDao extends PagingAndSortingRepository<Tarea, Long>, CustomTareaDao {
/**
* Recupera todas las tareas del usuario que le pasamos, para la fecha dada.
*
* @author Alguien.
* @param idUsuario
* {@link Long} con el ID del usuario duenio de la tarea.
* @param fechaDesde
* {@link Date} la fecha desde la cual se buscara.
* @param fechaHasta
* {@link Date} la fecha hasta la cual se buscara.
* @param sort
* {@link Sort} de Spring Data JPA utilizado para ordenar los
* resultados segun cierto criterio.
* @return {@link List<Tarea>} Las tareas encontradas.
*/
List<Tarea> findByUsuarioIdAndFechaBetween(Long idUsuario, Date fechaDesde, Date fechaHasta, Sort sort);
}

Como vemos, estamos definiendo un método '''findByUsuarioIdAndFechaBetween''' que sigue la nomenclatura del framework para recuperar un listado de tareas en base al Id del Usuario que le pasamos, entre un rango de fechas dado, y que al definir con esta nomenclatura hacemos que la implementación quede a cargo del framework.

====Usando el DAO desde el Service====
Ahora, nuestro Service cuenta con un DAO que tiene:
* Métodos definidos en él;
* Métodos provistos por PagingAndSortingRepository;
* Métodos provistos por CustomTareaDao.

¿Y las implementaciones?

Las implementaciones de los métodos definidos en TareaDao y los heredados de PagingAndSortingRepository, nos las va a proveer el framework. Y para la interfaz CustomTareaDao nosotros debemos definir nuestro DaoImpl común y corriente.

====Test====
A la hora de testear, debemos tener un test (en nuestro caso es TareaDaoComponenteTest) que testee de la interfaz DAO que exponemos (es decír, TareaDao):
* Los métodos definidos manualmente en el DAO siguiendo la nomenclatura específica del framework. Ej: List<Tarea> findByUsuarioIdAndFechaBetween(Long idUsuario, Date fechaDesde, Date fechaHasta, Sort sort);
* Los métodos definidos en la interfaz creada para los métodos específicos (CustomTareaDao). Ej: ScrollableResults buscarResumenHoras(FiltroResumenHorasDto filtro);

===Test===
Como estamos delegando la responsabilidad de la implementación del DAO en un framework, y como ni siquiera sabemos como es la implementación dado que se produce en runtime, decidimos no testear aquellos métodos ya tenemos definidos al heredar de alguna de las interfaces que nos provee la herramienta.
Sin embargo, sí decidimos testear la capa del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA, además claro de la lógica propia del Service.

Archivo:Ejemplo complejo Spring Data JPA.PNG

2012-05-08T15:03:03Z

Barrios.nahuel: Ejemplo de interfaz DAO utilizando Spring Data JPA y extendiendo además de una interfaz propia.

Ejemplo de interfaz DAO utilizando Spring Data JPA y extendiendo además de una interfaz propia.

Spring Data

2012-05-08T15:01:28Z

Barrios.nahuel: Creo la página con ejemplos de Spring Data JPA

==Introducción==
La herramienta que encontramos útil para dejar de hacer manualmente las implementaciones de los DAO que suelen ser siempre de la misma manera, fué a través de Spring Data JPA. [http://www.springsource.org/spring-data/jpa|http://www.springsource.org/spring-data/jpa]

Este framework nos permite, siguiendo una serie de normas que nos establece, crear interfaces de DAOs definiendo métodos y NO realizar ninguna implementación. Es decir, dejamos la responsabilidad de la implementación al framework, el cuál hará la implementación en tiempo de corrida.
Para ello, el framework básicamente lo que hace es buscar, dado un paquete que le indicamos por configuración, todas las interfaces que hereden de org.springframework.data.repository.Repository<T, ID extends Serializable> ya sea directa o indirectamente.

[[Archivo:Spring-Data-JPA-Herencia repository.PNG]]

==Configuración==

===Dependencias (Utilizando Maven)===
Para trabajar con Spring Data JPA, solo debemos agregar la dependencia:
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.0.3.RELEASE</version>
</dependency>

Siempre y cuando contemos con una configuración de persistencia que utilice:
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
<property name="jpaDialect">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaDialect" />
</property>
</bean>
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="defaultDataSource" />
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="generateDdl" value="false" />
</bean>
</property>
</bean>

===Configurando el paquete a escanear===

En el applicationContext.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jpa="http://www.springframework.org/schema/data/jpa"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://www.springframework.org/schema/data/jpa http://www.springframework.org/schema/data/jpa/spring-jpa.xsd">
.
.
.

<jpa:repositories base-package="com.th.ctc.dao" />
.
.
.
</beans>

==Implementación==
===El ejemplo fácil===
====Definiendo la interfaz del DAO====
Para este ejemplo sencillo, la interfaz del DAO va a quedar sin métodos definidos explicitamente, pero con todos aquellos que estamos heredando.

import org.springframework.data.repository.CrudRepository;
import com.th.ctc.domain.Cliente;
/**
* Interfaz del DAO para la entidad {@link Cliente}. Esta interfaz NO tiene una
* implementacion concreta dado que al extender de Repository la implementacion
* la hace en runtime Spring Data JPA.
*
* @author Alguien.
*/
public interface ClienteDao extends CrudRepository<Cliente, Long> {
}

====Usando el DAO desde el Service====
Hasta acá llegamos. A partir de ahora no hay mas código vinculado con el DAO más que el uso de los métodos que estamos exponiendo en la interfaz que nosotros mismos creamos. Por lo tanto nuestro Service sería algo como:

/**
* DAO de clientes.
*/
@Autowired
private ClienteDao clienteDao;
@Override
public List<Cliente> buscarTodos() {
return (List<Cliente>) clienteDao.findAll(); //El método findAll() proviene de CrudRepository
}

====Test====
Como no hay una implementación concreta, y de haber, no la hacemos nosotros sino que estamos delegando la responsabilidad al framework, no hacemos tests de la capa DAO, pero si del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA además claro de la lógica propia del Service.

===El ejemplo habitual===

====Definiendo la interfaz del DAO====
Para este ejemplo sencillo, la interfaz del DAO va a quedar sin métodos definidos explicitamente, pero con todos aquellos que estamos heredando.

import org.springframework.data.repository.PagingAndSortingRepository;
import com.th.ctc.domain.Usuario;
/**
* Interfaz del DAO para la entidad {@link Usuario}. Esta interfaz NO tiene una
* implementacion concreta dado que al extender de Repository la implementación
* la hace en runtime Spring Data JPA.
*
* @author Alguien.
*/
public interface UsuarioDao extends PagingAndSortingRepository<Usuario, Long> {
}

====Usando el DAO desde el Service====
Hasta acá llegamos. A partir de ahora no hay mas código vinculado con el DAO más que el uso de los métodos que estamos exponiendo en la interfaz que nosotros mismos creamos. Por lo tanto nuestro Service sería algo como:

/**
* DAO de usuarios.
*/
@Autowired
private UsuarioDao usuarioDao;
@Override
public List<Usuario> buscarTodos() {
// El método findAll(Sort) proviene de PagingAndSortingRepository y con el String "apellido" (es el nombre del
// atributo de clase de la entidad Usuario) estamos indicando que se ordenaran los resultados por ese campo
return (List<Usuario>) usuarioDao.findAll(new Sort("apellido"));
}

====Test====
Como no hay una implementación concreta, y de haber, no la hacemos nosotros sino que estamos delegando la responsabilidad al framework, no hacemos tests de la capa DAO, pero si del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA además claro de la lógica propia del Service.

===El ejemplo dificil===
Supongamos que ahora necesitamos 2 cosas:
Por un lado, recuperar todos los elementos de una entidad, recuperar uno solo en base al ID y etc., y por otro, generar un archivo Excel con información recuperada de una consulta a una base de datos muy específica.
Para lograr esto, aprovechando esta herramienta, necesitamos 2 interfaces del DAO. Una para definir estos métodos tan complejos que necesitamos, y otra para utilizar de la misma manera que en el ejemplo fácil.

¿Pero entonces el Service tiene que utilizar 2 DAOs distintos sobre la misma entidad?

No. Antes que nada, veamos un diagrama de clases para que veamos por qué este es el ejemplo dificil:
[[Archivo:Ejemplo complejo Spring Data JPA.PNG]]

Es decir, tenemos un Service (TareaServiceImpl) que utiliza un DAO (TareaDao). Nada nuevo hasta acá. Sin embargo, este TareaDao no solo hereda de Repository al heredar de org.springframework.data.repository.PagingAndSortingRepository, sino que también está heredando de una interfaz definida por nosotros (CustomTareaDao).

¿Por qué necesitamos esto?

Bueno, por que si bien podemos definir métodos en la interfaz que hereda de Repository, estos métodos tienen que seguir una nomenclatura específica para que el framework pueda hacer la implementación y, además, porque no podemos definir métodos que no queremos que los implemente Spring Data JPA para implementarlos nosotros.

====Definiendo la interfaz del DAO====

import java.util.Date;
import java.util.List;
import org.springframework.data.domain.Sort;
import org.springframework.data.repository.PagingAndSortingRepository;
import com.th.ctc.domain.Tarea;
/**
* Interfaz el DAO de las {@link Tarea} implementado por Spring Data JPA.
*
* @author Alguien.
*/
public interface TareaDao extends PagingAndSortingRepository<Tarea, Long>, CustomTareaDao {
/**
* Recupera todas las tareas del usuario que le pasamos, para la fecha dada.
*
* @author Alguien.
* @param idUsuario
* {@link Long} con el ID del usuario duenio de la tarea.
* @param fechaDesde
* {@link Date} la fecha desde la cual se buscara.
* @param fechaHasta
* {@link Date} la fecha hasta la cual se buscara.
* @param sort
* {@link Sort} de Spring Data JPA utilizado para ordenar los
* resultados segun cierto criterio.
* @return {@link List<Tarea>} Las tareas encontradas.
*/
List<Tarea> findByUsuarioIdAndFechaBetween(Long idUsuario, Date fechaDesde, Date fechaHasta, Sort sort);
}

Como vemos, estamos definiendo un método '''findByUsuarioIdAndFechaBetween''' que sigue la nomenclatura del framework para recuperar un listado de tareas en base al Id del Usuario que le pasamos, entre un rango de fechas dado, y que al definir con esta nomenclatura hacemos que la implementación quede a cargo del framework.

====Usando el DAO desde el Service====
Ahora, nuestro Service cuenta con un DAO que tiene:
* Métodos definidos en él;
* Métodos provistos por PagingAndSortingRepository;
* Métodos provistos por CustomTareaDao.

¿Y las implementaciones?

Las implementaciones de los métodos definidos en TareaDao y los heredados de PagingAndSortingRepository, nos las va a proveer el framework. Y para la interfaz CustomTareaDao nosotros debemos definir nuestro DaoImpl común y corriente.

====Test====
A la hora de testear, debemos tener un test (en nuestro caso es TareaDaoComponenteTest) que testee de la interfaz DAO que exponemos (es decír, TareaDao):
* Los métodos definidos manualmente en el DAO siguiendo la nomenclatura específica del framework. Ej: List<Tarea> findByUsuarioIdAndFechaBetween(Long idUsuario, Date fechaDesde, Date fechaHasta, Sort sort);
* Los métodos definidos en la interfaz creada para los métodos específicos (CustomTareaDao). Ej: ScrollableResults buscarResumenHoras(FiltroResumenHorasDto filtro);

===Test===
Como estamos delegando la responsabilidad de la implementación del DAO en un framework, y como ni siquiera sabemos como es la implementación dado que se produce en runtime, decidimos no testear aquellos métodos ya tenemos definidos al heredar de alguna de las interfaces que nos provee la herramienta.
Sin embargo, sí decidimos testear la capa del Service donde probamos que estamos utilizando correctamente lo que nos provee Spring DATA JPA, además claro de la lógica propia del Service.

Archivo:Spring-Data-JPA-Herencia repository.PNG

2012-05-08T15:00:28Z

Barrios.nahuel: Muestro la herencia de las interfaces de Spring Data JPA: Repository; CrudRepository; PagingAndSortingRepository.

Muestro la herencia de las interfaces de Spring Data JPA:
Repository; CrudRepository; PagingAndSortingRepository.

Spring Data

2012-05-08T14:52:38Z

Barrios.nahuel: Página creada con 'asdasdasdasd'

asdasdasdasd

Desarrollo De Software

2012-05-08T14:52:05Z

Barrios.nahuel: /* Ver también */

El desarrollo de software involucra no sólo el uso de [[Metodologias De Desarrollo]], sino la aplicación de tecnologías de desarrollo y testing para asegurar la calidad del producto.

== Libros ==
* [[Libros]]

== Ver también ==
* [[HTML]]
* [[Javascript]]
* [[Java]]
* [[Diseño De Software]]
* [[Patrones]]
* [[Testing De Aplicaciones]]
* [[Base De Datos]]
* [[Herramientas Para Gestion De Calidad]]
* [[Performance De Aplicaciones]]
* [[Spring Data]]