Si trabajas con Java y bases de datos, llega un momento en que mezclar consultas SQL dentro del main se vuelve un caos. Aquí entra el patrón Repository en Java, una forma de separar la lógica de negocio de la lógica de acceso a datos para que tu código sea más limpio, testeable y escalable.

¿Qué es el patrón Repository y por qué usarlo en Java?

El patrón Repository actúa como un intermediario entre tu aplicación y la base de datos. En lugar de que cada parte del programa abra conexiones y ejecute queries, delegas todo eso a clases especializadas.

¿Qué hace el patrón Repository? Aísla el acceso a datos en una capa independiente. Tu lógica de negocio le pide datos al repositorio, sin saber si vienen de MySQL, PostgreSQL o un archivo.

La estructura que vas a montar se apoya en tres paquetes:

• util: contiene la clase DatabaseConnection que maneja la conexión.
• model: guarda la entidad Employee con sus atributos y métodos.
• repository: aloja la interfaz Repository y la clase EmployeeRepository que implementa los métodos.

¿Cómo modelar la entidad Employee con sus atributos?

Dentro del paquete model creas la clase Employee, que representa a un empleado tal como existe en la base de datos. Los atributos deben llamarse igual que las columnas para evitar confusiones al mapear.

Atributos privados de la entidad

Declara cada campo como private para respetar el encapsulamiento:

• private int id.
• private String firstName.
• private String surname.
• private String email.
• private double salary.

Después usas el atajo alt + insert en IntelliJ para generar lo que falta sin escribir línea por línea.

Constructores, getters, setters y toString

Necesitas dos constructores: uno vacío para instanciar objetos sin datos iniciales y otro completo que reciba todos los atributos. A esto sumas los getters y setters de cada campo, más el método toString para imprimir empleados de forma legible cuando los recuperes desde la base.

¿Por qué incluir un constructor vacío? Muchos frameworks y librerías de Java necesitan instanciar objetos sin parámetros para luego poblar los campos vía setters o reflection.

¿Cómo crear una conexión Singleton a la base de datos?

En el paquete util creas DatabaseConnection, una clase que centraliza la conexión usando el patrón Singleton. La idea es simple: garantizar que durante toda la ejecución del programa exista una sola instancia de la conexión, en lugar de abrir y cerrar varias.

Variables estáticas para credenciales

Define las credenciales como atributos estáticos privados de la clase:

• URL con la dirección JDBC de tu base.
• USER con tu usuario.
• PASSWORD con tu contraseña.
• Un objeto Connection llamado myConn que arranca en null.

Recuerda que estas credenciales son personales: la URL, el usuario y la contraseña que veas en el video son del instructor, tú usas las tuyas.

El método getInstance paso a paso

El corazón del Singleton es el método getInstance. Su lógica es directa:

java public static Connection getInstance() throws SQLException { if (myConn == null) { myConn = DriverManager.getConnection(URL, USER, PASSWORD); } return myConn; }

Si myConn es null, abre la conexión con DriverManager.getConnection pasando la URL, el usuario y la contraseña. Si ya existe, simplemente la retorna. Así reutilizas siempre la misma conexión.

¿Qué es un Singleton en Java? Es un patrón de diseño que asegura que una clase tenga una única instancia accesible globalmente, ideal para conexiones, configuraciones o loggers.

¿Cómo usar DatabaseConnection desde el método main?

Antes tenías la URL, el usuario y la contraseña sueltas dentro del main, abriendo la conexión directamente ahí. Con el refactor, eliminas esas tres variables del main y dentro del bloque try reemplazas la conexión manual por una llamada limpia:

java Connection conn = DatabaseConnection.getInstance();

Con esa línea, el main ya no sabe nada de credenciales ni de drivers. Toda esa responsabilidad vive en util. Si mañana cambias de motor de base de datos o rotas las contraseñas, tocas un solo archivo.

¿Qué sigue después de configurar el Repository?

Con la entidad modelada y la conexión centralizada, ya tienes los cimientos del patrón. El siguiente paso es definir la interfaz Repository con los métodos del CRUD (crear, leer, actualizar y eliminar) y luego implementarlos dentro de EmployeeRepository, que es donde escribirás las consultas SQL reales.

La ventaja de este orden es clara: cuando llegues a escribir queries, tu código de negocio ya estará desacoplado y podrás cambiar la implementación sin romper nada más.

¿Ya tienes claro cómo se conectan los paquetes util, model y repository en tu proyecto? Cuéntame en los comentarios qué parte te gustaría profundizar primero.