AD-tarea31/RESUMEN.md

User: Puedes explicarme como una profesora de DAM este codigo, desde por que cada clase , lo que hace, sus estructura, y un mapa grafico de como se llaman a las clases etc

GitHub Copilot: Optimizando selección de herramientas...¡Hola, futuros técnicos y técnicas en Desarrollo de Aplicaciones Multiplataforma!

Soy GitHub Copilot, y hoy voy a ser vuestra profesora para desgranar este proyecto Java. Vamos a ver cómo está montado, por qué se estructura así y cómo se comunican las distintas partes. ¡Al lío, que el código no espera!

### 1. ¿Qué estamos viendo? La foto general

Imaginad que estamos construyendo una aplicación de escritorio para gestionar cuentas bancarias y empleados de una empresa. No queremos mezclar el código que pinta las ventanas con el que habla con la base de datos, ¿verdad? Sería un caos.

Por eso, usamos una **arquitectura en capas**. Cada capa tiene una responsabilidad muy concreta. Es como en una cocina: tienes al que prepara los ingredientes, al que cocina y al que sirve el plato. Cada uno a lo suyo, pero todos coordinados.

Aquí tenemos las siguientes capas:

1.  **Capa de Presentación (la Interfaz Gráfica - GUI):** Lo que el usuario ve y con lo que interactúa. En nuestro caso, son las ventanas creadas con Java Swing (`AccountWindow.java`).
2.  **Capa de Servicio (la Lógica de Negocio):** El "cerebro" de la aplicación. Aquí se definen las operaciones que se pueden hacer. Por ejemplo, "crear una cuenta" implica no solo guardarla, sino también validar que los datos son correctos.
3.  **Capa de Acceso a Datos (DAO - Data Access Object):** El único que sabe "hablar" con la base de datos. Su trabajo es coger objetos Java y guardarlos en tablas, o leer datos de las tablas y convertirlos en objetos Java.
4.  **Capa de Modelo (las Entidades):** Son las "plantillas" de los datos que manejamos: `Account`, `Employee`, etc. Son simples clases Java (POJOs) que representan las tablas de nuestra base de datos.

### 2. El mapa de clases: ¿Quién llama a quién?

Para que os hagáis una idea visual, las llamadas suelen seguir este flujo. El usuario hace clic en un botón y se desencadena una cascada de llamadas hacia abajo. La respuesta viaja en sentido contrario.

Aquí tenéis un diagrama para que lo veáis más claro.

 



¡Hola a todos! Como vuestra profesora de Desarrollo de Aplicaciones Multiplataforma, hoy vamos a desgranar esta aplicación de ejemplo para que entendáis perfectamente su estructura y funcionamiento. Es un ejemplo clásico de cómo se construyen las aplicaciones hoy en día, siguiendo una arquitectura en capas. ¡Vamos a ello!

### Arquitectura General: El Patrón en Capas

Imaginad que estamos construyendo una casa. No ponemos el tejado antes que los cimientos, ¿verdad? En software hacemos algo parecido. Organizamos el código en capas, donde cada una tiene una responsabilidad muy concreta. Esto hace que el código sea más fácil de entender, de mantener y de hacer crecer.

En este proyecto, tenemos las siguientes capas, como podéis ver en el diagrama que he generado:

1.  **Capa de Presentación (GUI):** Es lo que el usuario ve y con lo que interactúa. En nuestro caso, es la ventana `AccountWindow`.
2.  **Capa de Servicio:** Contiene la lógica de negocio de la aplicación. Orquesta las operaciones y decide "qué" hacer. Aquí tenemos `AccountServicio`.
3.  **Capa de Acceso a Datos (DAO):** Se encarga de hablar con la base de datos. Su única misión es leer y escribir datos. Aquí encontramos `AccountDaoHibernate`.
4.  **Capa de Modelo:** Representa los datos con los que trabajamos. Son nuestras "plantillas" de objetos, como `Account` o `Emp`.

Ahora, veamos cada pieza del puzzle.

---

### 1. Capa de Modelo: Los Datos

Son clases "tontas" (a veces llamadas POJOs - Plain Old Java Objects) que solo tienen atributos (las variables), y sus `getters` y `setters`. No hacen nada más que guardar información.

*   **`Account.java`**: Representa una cuenta bancaria en nuestro sistema. Tendrá atributos como `id`, `nombre_cliente`, `saldo`, etc.
*   **`AccMovement.java`**: Representa un movimiento dentro de una cuenta.
*   **`Emp.java`**, **`Dept.java`**, **`Project.java`**: Otras entidades que representan empleados, departamentos y proyectos.

---

### 2. Capa de Acceso a Datos (DAO - Data Access Object)

Esta capa es la única que sabe cómo se guardan y se recuperan los datos de la base de datos. Si el día de mañana cambiamos de MariaDB a Oracle, ¡solo tendríamos que modificar esta capa!

*   **`IAccountDao.java`**: Es una **interfaz**. Define las "reglas del juego". Dice qué operaciones se pueden hacer con las cuentas (ej: `guardarCuenta`, `buscarCuentaPorId`, `eliminarCuenta`). No dice *cómo* se hacen, solo *qué* se puede hacer. Esto es genial porque nos permite cambiar la implementación sin tocar el resto del código.

*   **`AccountDaoHibernate.java`**: Es la **implementación** de la interfaz `IAccountDao`. Esta clase sí sabe cómo hacer las operaciones usando **Hibernate**, que es un framework que nos facilita enormemente el trabajo con bases de datos. En lugar de escribir SQL a mano, trabajamos con los objetos (`Account`, `Emp`, etc.) y Hibernate se encarga de "traducirlo" a SQL.

*   **`HibernateUtil.java`**: Es una clase de utilidad que se encarga de configurar y arrancar Hibernate, creando un objeto muy importante llamado `SessionFactory`. Piensa en el `SessionFactory` como la "fábrica" que nos da las conexiones (sesiones) a la base de datos.

---

### 3. Capa de Servicio: La Lógica de Negocio

Esta capa es el cerebro de la aplicación. Utiliza el DAO para obtener los datos y aplica la lógica de negocio sobre ellos. Por ejemplo, para hacer una transferencia, el servicio pediría al DAO la cuenta de origen y la de destino, comprobaría que hay saldo suficiente (¡lógica de negocio!), modificaría los saldos y le diría al DAO que guarde los cambios.

*   **`IAccountServicio.java`**: Al igual que en la capa DAO, es una interfaz que define las operaciones de negocio. Por ejemplo: `crearCuenta`, `realizarTransferencia`, `consultarSaldo`.

*   **`AccountServicio.java`**: Es la implementación de la interfaz `IAccountServicio`. Dentro de esta clase es donde se llama al `AccountDaoHibernate` para pedirle o mandarle datos. Por ejemplo, el método `crearCuenta` de `AccountServicio` llamará al método `guardarCuenta` de `AccountDaoHibernate`.

---

### 4. Capa de Presentación (GUI - Graphical User Interface)

Es la parte visible, la que interactúa con la persona que usa la aplicación.

*   **`AccountWindow.java`**: Es una clase que extiende de `JFrame` o similar (usando Swing, JavaFX...). Contiene los botones, campos de texto, tablas, etc. Cuando el usuario pulsa el botón "Guardar Cuenta", esta clase no habla directamente con la base de datos. ¡No! Llama al método correspondiente de la capa de servicio (por ejemplo, a `accountServicio.crearCuenta(...)`). La ventana no sabe (ni le importa) si los datos se guardan en Hibernate, en un fichero o en la nube.

### Flujo de una Operación: "Crear una Cuenta"

Para que lo veáis claro, sigamos el flujo de una operación:

1.  El **usuario** rellena los datos en la ventana (`AccountWindow`) y pulsa "Guardar".
2.  `AccountWindow` recoge los datos de los campos de texto, crea un objeto `Account` y llama al método `crearCuenta` de su objeto `IAccountServicio`.
3.  La implementación, `AccountServicio`, recibe la petición. Aquí podría aplicar lógica (ej: comprobar que el saldo inicial no es negativo). Luego, llama al método `guardar` de su objeto `IAccountDao`.
4.  La implementación, `AccountDaoHibernate`, recibe el objeto `Account`. Usa Hibernate para abrir una sesión, iniciar una transacción y guardar el objeto en la base de datos.
5.  Si todo va bien, la operación finaliza y se puede mostrar un mensaje de éxito al usuario en `AccountWindow`.

Espero que esta explicación os haya aclarado la estructura. Este patrón de diseño (Capas + Interfaces + DAO + Servicio) es muy potente y se usa muchísimo en el mundo profesional. ¡Ahora a revisar el código y a preguntar todas las dudas que tengáis