spring data jdbc

Spring DAO vs Spring ORM vs Spring JDBC

Question

Estaba revisando las tecnologías de acceso a datos compatibles con Spring, y noté que menciona múltiples opciones y no estoy seguro de la diferencia entre ellas:

• Spring-DAO ( http://docs.spring.io/spring/docs/2.0.8/reference/dao.html )
• Spring-ORM ( http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/orm.html )
• Spring-JDBC ( http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/jdbc.html )

Según tengo entendido, Spring JDBC proporciona plantillas para reducir el código repetitivo para acceder a una base de datos de la manera más simple: usted escribe sus propias consultas SQL.

Spring-ORM proporciona plantillas simplificadas para acceder a bases de datos a través de tecnologías ORM, como Hibernate, My (i) Batis, etc.

Spring-DAO según el sitio web de Spring:

El soporte de Data Access Object (DAO) en Spring tiene como objetivo facilitar el trabajo con tecnologías de acceso a datos como JDBC, Hibernate o JDO de forma coherente.

Estoy un poco claro acerca de ORM vs JDBC, ya que están dirigidos a diferentes formas de acceder a la base de datos. ¡Pero Spring-DAO es simplemente confuso!

¿Podría alguien aclarar cuáles son exactamente las diferencias entre estos tres? ¿Cuál debería ser el preferido en qué escenarios?

Además, hay otro proyecto disponible también en Spring-DATA ( http://projects.spring.io/spring-data/ ). Ahora, es un proyecto parental para todos los técnicos de acceso a datos compatibles con Spring o solo es un nuevo nombre para Spring-DAO?

Answer 1

Aquí hay una introducción a cada tecnología mencionada.

Spring-DAO

Spring-DAO no es estrictamente un módulo de resorte, sino más bien convenciones que deberían dictarle que escriba DAO y que las escriba bien. Como tal, no proporciona interfaces ni implementaciones ni plantillas para acceder a sus datos. Al escribir un DAO, debe anotarlos con @Repository para que las excepciones vinculadas a la tecnología subyacente (JDBC, Hibernate, JPA, etc.) se traduzcan de manera consistente en la subclase de DataAccessException adecuada.

Como ejemplo, supongamos que está utilizando Hibernate, y su capa de servicio detecta HibernateException para reaccionar. Si cambia a JPA, sus interfaces DAO no deberían cambiar, y la capa de servicio aún se compilará con bloques que capturen HibernateException , pero nunca ingresará estos bloques ya que sus DAO ahora están lanzando JPA PersistenceException . Al usar @Repository en su DAO, las excepciones vinculadas a la tecnología subyacente se traducen en Spring DataAccessException ; su capa de servicio capta estas excepciones y, si decide cambiar la tecnología de persistencia, las mismas DataAccessExceptions Spring DataAccessExceptions se DataAccessExceptions cuando Spring haya traducido las excepciones nativas.

Sin embargo, tenga en cuenta que esto tiene un uso limitado por los siguientes motivos:

1. Por lo general, no debería capturar las excepciones de persistencia, ya que el proveedor puede haber retrotraído la transacción (según el subtipo de excepción exacto) y, por lo tanto, no debe continuar la ejecución con una ruta alternativa.
2. La jerarquía de excepciones generalmente es más rica en su proveedor que lo que proporciona Spring, y no hay un mapeo definitivo de un proveedor a otro. Confiar en esto es peligroso. Sin embargo, es una buena idea anotar sus DAO con @Repository , ya que los beans se agregarán automáticamente mediante el procedimiento de escaneo. Además, Spring puede agregar otras funciones útiles a la anotación.

Spring-JDBC

Spring-JDBC proporciona la clase JdbcTemplate, que elimina el código de plomería y le ayuda a concentrarse en la consulta SQL y los parámetros. Solo necesita configurarlo con un DataSource , y luego puede escribir un código como este:

int nbRows = jdbcTemplate.queryForObject("select count(1) from person", Integer.class);

Person p = jdbcTemplate.queryForObject("select first, last from person where id=?", 
             rs -> new Person(rs.getString(1), rs.getString(2)), 
             134561351656L);

Spring-JDBC también proporciona JdbcDaoSupport, que puede ampliar para desarrollar su DAO. Básicamente define 2 propiedades: un DataSource y un JdbcTemplate que se pueden usar para implementar los métodos DAO. También proporciona un traductor de excepciones desde excepciones de SQL a Spring DataAccessExceptions.

Si planea usar jdbc simple, este es el módulo que necesitará usar.

Spring-ORM

Spring-ORM es un módulo paraguas que cubre muchas tecnologías de persistencia, a saber, JPA, JDO, Hibernate e iBatis. Para cada una de estas tecnologías, Spring proporciona clases de integración para que cada tecnología se pueda utilizar siguiendo los principios de configuración de Spring y se integra sin problemas con la gestión de transacciones de Spring.

Para cada tecnología, la configuración consiste básicamente en inyectar un bean DataSource en algún tipo de bean SessionFactory o EntityManagerFactory etc. Para JDBC puro, no hay necesidad de tales clases de integración (aparte de JdbcTemplate), ya que JDBC solo depende de un DataSource.

Si planea usar un ORM como JPA o Hibernate, no necesitará spring-jdbc, sino solo este módulo.

Spring-Data

Spring-Data es un proyecto global que proporciona una API común para definir cómo acceder a los datos (anotaciones DAO +) de una manera más genérica, que abarca fuentes de datos SQL y NOSQL.

La idea inicial es proporcionar una tecnología para que el desarrollador escriba la interfaz para un DAO (métodos de búsqueda) y las clases de entidad de una manera independiente de la tecnología y, basándose solo en la configuración (anotaciones en DAO y entidades + configuración de primavera, ya sea xml- o basado en Java), decide la tecnología de implementación, ya sea JPA (SQL) o redis, hadoop, etc. (NOSQL).

Si sigue las convenciones de nomenclatura definidas por la primavera para los nombres de los métodos del buscador, ni siquiera necesita proporcionar las cadenas de consulta correspondientes a los métodos del buscador para los casos más simples. Para otras situaciones, debe proporcionar la cadena de consulta dentro de las anotaciones en los métodos de búsqueda.

Cuando se carga el contexto de la aplicación, Spring proporciona proxies para las interfaces DAO, que contienen todo el código repetitivo relacionado con la tecnología de acceso a datos e invoca las consultas configuradas.

Spring-Data se concentra en tecnologías que no son SQL, pero aún proporciona un módulo para JPA (la única tecnología SQL).

Que sigue

Sabiendo todo esto, ahora tiene que decidir qué elegir. La buena noticia es que no necesita hacer una elección final definitiva para la tecnología. Aquí reside realmente el poder de Spring: como desarrollador, usted se concentra en el negocio cuando escribe código, y si lo hace bien, cambiar la tecnología subyacente es un detalle de implementación o configuración.

1. Defina un modelo de datos con clases POJO para las entidades, y obtenga / configure métodos para representar los atributos de la entidad y las relaciones con otras entidades. Seguramente tendrá que anotar las clases de entidad y los campos en función de la tecnología, pero por ahora, los POJO son suficientes para comenzar. Solo concéntrese en los requisitos del negocio por ahora.
2. Definir interfaces para sus DAO. 1 DAO cubre exactamente 1 entidad, pero ciertamente no necesitará un DAO para cada uno de ellos, ya que debería poder cargar entidades adicionales navegando por las relaciones. Defina los métodos del buscador siguiendo estrictas convenciones de nomenclatura.
3. En función de esto, alguien más puede comenzar a trabajar en la capa de servicios, con burlas para sus DAO.
4. Aprende las diferentes tecnologías de persistencia (sql, no-sql) para encontrar la mejor opción para sus necesidades, y elija una de ellas. De acuerdo con esto, usted anota las entidades e implementa los DAO (o permite que la primavera los implemente si elige usar los datos de primavera).
5. Si los requisitos del negocio evolucionan y su tecnología de acceso a los datos no es suficiente para respaldarla (por ejemplo, comenzó con JDBC y algunas entidades, pero ahora necesita un modelo de datos más rico y JPA es una mejor opción), tendrá que cambiar la implementación de sus DAO, agregue algunas anotaciones en sus entidades y cambie la configuración del resorte (agregue una definición de EntityManagerFactory). El resto de su código comercial no debe ver otros impactos de su cambio.

Nota: Gestión de transacciones

Spring proporciona una API para la gestión de transacciones. Si planea usar la primavera para el acceso a los datos, también debe usar la primavera para la administración de transacciones, ya que se integran muy bien. Para cada tecnología de acceso a datos compatible con la primavera, existe un administrador de transacciones correspondiente para las transacciones locales, o puede elegir JTA si necesita transacciones distribuidas. Todos ellos implementan la misma API, por lo que (una vez más) la elección de la tecnología es solo una cuestión de configuración que puede modificarse sin mayor impacto en el código comercial.

Nota: documentación de primavera

Los enlaces a la documentación de Spring que mencionó son bastante antiguos. Aquí está la documentación de la última versión (4.1.6, que cubre todos los temas):

• Página html única: http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/
• PDF: http://docs.spring.io/spring/docs/current/spring-framework-reference/pdf/spring-framework-reference.pdf

Spring-data no es parte del marco Spring. Hay un módulo común que primero debe leer para acostumbrarse a los principios. La documentación se puede encontrar aquí:

• Página html única: http://docs.spring.io/spring-data/data-commons/docs/1.9.2.RELEASE/reference/html/
• PDF: http://docs.spring.io/spring-data/data-commons/docs/1.9.2.RELEASE/reference/pdf/spring-data-commons-reference.pdf

Answer 2

Crea una interfaz como SomeObjectDao y luego crea diferentes implementaciones de esta interfaz como JdbcSomeObjectDao , HibernateSomeObjectDao . Luego, en su clase SomeObjectService , operará en la interfaz SomeObjectDao e inyectará allí una de las implementaciones concretas. Por lo tanto, cada implementación de SomeObjectDao ocultará los detalles, ya sea que utilice JDBC o ORM, etc.

Por lo general, JDBC y diferentes implementaciones de ORM arrojan diferentes tipos de excepciones. El soporte DAO de Spring puede asignar esas excepciones diferentes, tecnológicas y específicas a las excepciones comunes de Spring DAO. Entonces estás desacoplado más de la implementación real. Además, el soporte DAO de Spring ofrece un conjunto de clases abstractas *DataSupport que ayudan aún más en el desarrollo DAO. Entonces, además de implementar su interfaz SomeObjectDao , puede extender una de las *DataSupport de Spring.

Answer 3

Spring DAO ( D ata A ccess O bject): es un objeto que proporciona una interfaz abstracta para los marcos de implementación JDBC, es decir, Spring DAO es un concepto generalizado para acceder a JDBC e Hibernate, MyBatis, JPA, JDO utilizando sus clases de soporte individuales. Y proporciona una jerarquía de excepción generalizada al definir la anotación @Repository . Esta anotación define al contenedor Spring para la traducción de excepciones SQL de SQLException a la jerarquía de DataAccessException estrategia de acceso a datos de Spring.

es decir, las excepciones específicas de la plataforma son capturas y luego se vuelven a lanzar como una de las excepciones de acceso a datos sin marcar de Spring.

Spring JDBC : Para JDBC simple utilizamos este módulo, que solo depende de las clases DataSource y Template como JdbcTemplate , NamedParameterJdbcTemplate (wraps JdbcTemplate ) y SimpleJdbcTemplate para reducir las preocupaciones de corte transversal.

public class EmployeeDao {  
private JdbcTemplate jdbcTemplate;  

public void setJdbcTemplate(JdbcTemplate jdbcTemplate) {  
    this.jdbcTemplate = jdbcTemplate;  
}  

public int saveEmployee(Employee e){  
    return jdbcTemplate.update(query);  
}  
public int updateEmployee(Employee e){  
    return jdbcTemplate.update(query);  
}  
public int deleteEmployee(Employee e){  
       return jdbcTemplate.update(query);  
}  

}  

y en Spring XML:

<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
    <property name="dataSource" ref="dataSource"/>
</bean>

Spring JDBC también proporciona JdbcDaoSupport , NamedParameterJdbcDaoSupport , SimpleJdbcDaoSupport , que son una forma de soporte (es decir, conveniente ) para ampliar y desarrollar nuestra propia interfaz abstracta DAO la siguiente manera:

public interface EmployeeDao {

    public void saveEmployee(Employee emp);
}

public class EmployeeDaoImpl extends JdbcDaoSupport implements EmployeeDao{

    @Override
    public void saveEmployee(Employee emp) {

        Object[] inputs = new Object[] {emp.getName(), emp.getSalary(), emp.getDept()};
        getJdbcTemplate().update(query, inputs);
    }
}

y en primavera XML:

<bean id="employeeDAO" class="EmployeeDaoImpl">
        <property name="dataSource" ref="dataSource" />
    </bean>

Spring ORM: para soporte de herramientas ORM, como Hibernate, JPA, MyBatis ... integra fácilmente Spring mediante la inyección de DataSource junto con las siguientes clases y clases respectivas de DaoSupport .

• SessionFactory para Hibernate
• EntityManagerFactory para JPA,
• SqlSessionFactory para MyBatis