DAO

DAO encapsula el acceso a la base de datos. Por lo que cuando la capa de lógica de negocio necesite interactuar con la base de datos, va a hacerlo a través de la API que le ofrece DAO. Generalmente esta API consiste en métodos CRUD (Create, Read, Update y Delete). Entonces por ejemplo cuando la capa de lógica de negocio necesite guardar un dato en la base de datos, va a llamar a un método create(). Lo que haga este método, es problema de DAO y depende de como DAO implemente el método create(), puede que lo implemente de manera que los datos se almacenen en una base de datos relacional como puede que lo implemente de manera que los datos se almacenen en ficheros de texto. Lo importante es que la capa de lógica de negocio no tiene porque saberlo, lo único que sabe es que el método create() va a guardar los datos, así como el método delete() va a eliminarlos, el método update() actualizarlos, etc. Pero no tiene idea de como interactúa DAO con la base de datos.

En una aplicación, hay tantos DAOs como modelos. Es decir, en una base de datos relacional, por cada tabla, habría un DAO.

DAO consiste básicamente en una clase que es la que interactúa con la base de datos. Los métodos de esta clase dependen de la aplicación y de lo que queramos hacer. Pero generalmente se implementan los métodos CRUD para realizar las “4 operaciones básicas” de una base de datos.

DTO

Los DTO (Data Transfer Object) son utilizados por DAO para transportar los datos desde la base de datos hacia la capa de lógica de negocio y viceversa. Por ejemplo, cuando la capa de lógica de negocio llama al método create(), ¿qué es lo que hace DAO? inserta un nuevo dato… ¿pero qué dato? el que la capa de lógica de negocio le pase como parámetro… ¿y cómo se lo pasa este dato? bueno, a través de un DTO.

Tiene como finalidad crear un objeto plano (POJO) con una serie de atributos que puedan ser enviados o recuperados del servidor en una sola invocación, de tal forma que un DTO puede contener información de múltiples fuentes o tablas y concentrarlas en una única clase simple.

Dado que el objetivo de un DTO es utilizarlo como un objeto de transferencia entre el cliente y el servidor, es importante evitar tener operaciones de negocio o métodos que realicen cálculos sobre los datos, es por ello que solo deberemos de tener los métodos GET y SET de los respectivos atributos del DTO.

Por ejemplo, si tuviéramos una base de datos relacional con una tabla empleados, con los campos id, nombre y salario. Entonces tendríamos que crear una clase EmpleadoDTO, con los atributos id, nombre y salario, que van a utilizar la capa de negocio y de persistencia para transportar los datos entre las dos capas.

Entonces cuando la capa de lógica de negocio quiera guardar un dato en la base de datos, va a crear un objeto EmpleadoDTO, a través de los accessors va a modificar los atributos, y después se lo va a pasar al método create() de DAO. Entonces DAO va a leer los datos del DTO, y los va a guardar en la base de datos.

Entidad vs DTO

Las entidades son clases que fueron diseñadas para mapear contra la base de datos, no para ser una vista para una pantalla o servicio determinado. Lo óptimo sería tener un DTO con todos los datos recogidos de la base de datos, y no modificar la entidad ya que nos llevará a una restructuración de la base de datos que busca cubrir los requerimientos de transferencia de datos, dejando de lado el verdadero propósito de la entidad, que es únicamente mapear contra la base de datos