Si trabajas con Java y necesitas separar la lógica de negocio del acceso a datos, los patrones DAO y Repository son dos herramientas que debes dominar. Ambos persiguen el mismo objetivo de fondo, pero se aplican en contextos distintos y con métodos diferentes. Aquí te explico cómo funcionan y en qué se diferencian.

¿Qué es el patrón DAO en Java?

El patrón Data Access Object (DAO) busca separar la lógica de negocio de la lógica de acceso a datos. La idea es que exista una entidad dedicada exclusivamente a hablar con tu fuente de datos, ya sea una base de datos o un archivo.

¿Qué significa DAO? Significa Data Access Object. Es un patrón que aísla el acceso a datos en una clase específica, de modo que tu lógica de negocio no sepa cómo se guardan o consultan los registros.

En la práctica, vas a crear una clase como EmpleadoDAO que contenga los métodos para acceder a una tabla concreta. Esa clase implementa una interfaz, y la interfaz es la única puerta de entrada para el resto de tu código. Toda la implementación real, las consultas SQL, las conexiones, las transacciones, vive dentro de la clase DAO y nunca se filtra hacia afuera.

¿Qué métodos incluye un DAO?

Un DAO típicamente expone operaciones CRUD completas, es decir, inserción, consulta, actualización y eliminación. Cada método mapea de forma bastante directa a una operación sobre tu tabla. Otra característica clave: el DAO está fuertemente ligado a una tabla específica de SQL. Si tienes una tabla empleados, tendrás un EmpleadoDAO. Si tienes productos, tendrás un ProductoDAO.

Fuera de tus clases DAO no debe existir ningún código que acceda directamente al repositorio de datos. Esa es la regla de oro.

¿Qué es el patrón Repository y en qué se diferencia del DAO?

El patrón Repository también separa la lógica de negocio de la lógica de persistencia, y por eso suele confundirse con el DAO. La diferencia está en el nivel de abstracción y en el tipo de métodos que expone.

Mientras el DAO está atado a una tabla SQL concreta, al Repository no le importa tanto el destino. Puede persistir en una base de datos relacional, en una NoSQL, en un archivo o en memoria; el sistema subyacente se vuelve un detalle de implementación.

¿Cuál es la diferencia entre DAO y Repository? El DAO está ligado a una tabla SQL específica y expone un CRUD completo. El Repository abstrae el origen de datos y ofrece métodos más reducidos orientados al dominio.

¿Qué métodos suele tener un Repository?

Aquí también trabajas con una interfaz y una clase que la implementa, pero los métodos son más acotados y conceptuales:

• findAll o buscar todos los registros.
• findById o buscar mediante un identificador.
• save, que internamente decide si hace una inserción o una actualización.
• delete para borrar un registro.

Fíjate en el detalle del método save. En un DAO clásico tendrías insert y update por separado. En un Repository, save resuelve esa diferencia por ti según si el objeto ya existe o no. Es una capa más alta, más cercana al lenguaje del negocio.

¿Cuándo conviene usar DAO y cuándo Repository?

La elección depende de qué tan acoplado quieras estar a tu fuente de datos. Si tu proyecto vive y morirá en SQL y necesitas control fino sobre cada operación de tabla, el DAO te da granularidad. Si quieres pensar en términos de objetos de dominio y poder cambiar el motor de persistencia sin reescribir tu lógica, el Repository te da flexibilidad.

Ambos comparten la misma filosofía: ningún código fuera de la capa de acceso debería tocar directamente la base de datos. Esa disciplina es la que mantiene tus proyectos Java mantenibles a largo plazo.

¿Cuál de los dos has usado más en tus proyectos? Cuéntame en los comentarios cómo lo aplicas.