[Informe de Clase] Desarrollo de Sistemas (2º año), Semana 36
~ Implementando migraciones y diseñando DAO: la semana que conecta la BD y la app ~
En la Semana 36, basándonos en el diagrama ER y el DDL creados la semana anterior, trabajamos en construir la base para operar la base de datos desde la aplicación.
El tema fue migraciones (creación de tablas) y diseño de DAO (capa de acceso a datos).
Fue una sesión práctica para aprender el proceso de “pegamento” que une el diseño de datos con la implementación.
■ Introducción del profesor: “El código que toca datos debe ser cuidadoso y deliberado”
Prof. Tanaka: “DAO es ‘código de frontera’ entre la app y la BD.
Debe diseñarse pensando en seguridad, legibilidad y resistencia al cambio.”
El profesor comenzó compartiendo un ejemplo real donde mezclar lógica de negocio y SQL hizo muy difíciles las modificaciones posteriores, y a partir de ahí explicó por qué usamos DAO (patrón Repository).
■ Puntos clave del día (resumen)
- Ejecutar el DDL para crear correctamente las tablas en el entorno local / de aprendizaje
- Separar el CRUD (Create / Read / Update / Delete) en una capa DAO
- Usar siempre placeholders para prevenir inyección SQL
- Definir claramente los límites de las transacciones
- Estandarizar el logging y el manejo de excepciones para mejorar la trazabilidad en operación
■ Ejercicio ①: Ejecutar migraciones (DDL)
Cada grupo ejecutó el DDL que había creado y comprobó si las tablas se creaban como se esperaba.
Checklist
- ¿Están las PK y FK correctamente definidas?
- ¿Se aplican bien las restricciones NOT NULL?
- ¿No faltan restricciones UNIQUE o CHECK?
- ¿Funcionan correctamente los INSERT de ejemplo?
- ¿Se comportan los JOIN como se esperaba?
Estudiante A: “Nos olvidamos de configurar una FK, así que el JOIN se comportaba raro… ¡menos mal que nos dimos cuenta!”
Estudiante B: “Me di cuenta de que solo con aplicar las restricciones se pueden prevenir errores desde pronto.”
■ Ejercicio ②: Diseño de DAO (definición de interfaces)
A continuación, discutimos la estructura de clases para los DAOs (Data Access Objects).
Rol del DAO (explicación del profesor)
- Centralizar la gestión del SQL
- Desacoplar la lógica de negocio de la base de datos
- Facilitar las pruebas (fácil de mockear)
- Mantener una estructura que no se derrumbe a medida que crece la aplicación
Métodos básicos de un DAO (Ejemplo: BooksDao)
get(book_id)find_by_title(keyword)create(book)update(book)delete(book_id)
Comentario de estudiantes: “Es cómodo tener el SQL en un solo sitio en lugar de repartido por todas partes. ¡Empiezo a entender eso de la ‘separación de responsabilidades’!”
■ Ejercicio ③: Implementación de un DAO
Implementamos operaciones CRUD en un entorno de aprendizaje usando SQLite / PostgreSQL.
Ejemplo: BooksDao (extracto, para aprendizaje)
class BooksDao:
def __init__(self, conn):
self.conn = conn
def get(self, book_id):
cur = self.conn.cursor()
cur.execute("SELECT id, title, author, is_available FROM books WHERE id = %s", (book_id,))
row = cur.fetchone()
return row
def create(self, title, author):
cur = self.conn.cursor()
cur.execute(
"INSERT INTO books (title, author) VALUES (%s, %s) RETURNING id",
(title, author)
)
new_id = cur.fetchone()[0]
self.conn.commit()
return new_id
Puntos de atención en la implementación de DAO
- Hacer rollback de las transacciones cuando ocurran excepciones
- Los datos inválidos deben ser rechazados antes de llegar al DAO (en la capa de servicio)
- Cualquier clase que use caché debe estar fuera del DAO (separación de responsabilidades)
- No registrar SQL en bruto directamente en los logs (por seguridad)
■ Ejercicio ④: Colaboración con la capa de servicio (separación de responsabilidades)
En vez de llamar a los DAOs directamente desde la UI, practicamos una estructura en la que se inserta una capa de Servicio (lógica de negocio) entre medio.
Responsabilidades de BooksService
- Comprobar si un libro se puede prestar
- Gestionar excepciones por retrasos en devoluciones
- Aplicar validaciones a las búsquedas por título
- Convertir los valores devueltos por el DAO a formatos amigables para la UI
Estudiante C: “Al escribirlo de verdad entendí mejor dónde debería estar la frontera entre DAO y servicio.”
■ Ejercicio ⑤: Mini prueba funcional (tabla → DAO → servicio)
Por último, hicimos una mini prueba con el siguiente flujo:
Insertar datos de ejemplo
→ Leer a través del DAO
→ Aplicar lógica en el Servicio
→ Verificar el resultado
Los equipos que se encontraron con excepciones investigaron la causa a partir de los logs y corrigieron los problemas en el momento.
La mayoría de los errores estaban relacionados con integridad de FK y restricciones de NULL, lo que resultó ser una buena oportunidad de aprendizaje.
■ Revisión y feedback
- Puntos positivos: Se respetaron las responsabilidades de los DAO, el SQL estaba bien organizado y los rollbacks en caso de excepción se implementaron adecuadamente.
- Puntos a mejorar: A veces los tipos de retorno eran ambiguos; en algunos equipos los servicios crecieron demasiado.
- Profesor: “Idealmente, los DAOs son ‘delgados’, los Servicios están ‘bien estructurados’ y los Controladores/UI son ‘mínimos’.”
■ Comentario de cierre del profesor
“El diseño que conecta la base de datos con la aplicación es una parte crucial que afecta directamente a la calidad.
El ‘diseño cuidadoso de la frontera’ que aprendisteis hoy os será muy útil también en desarrollos a gran escala.”
■ Tareas (para la próxima semana)
- Crear y entregar una lista de clases DAO y sus métodos por equipo.
- Dibujar un diagrama de clases sencillo de DAO y Servicio en una sola hoja.
- Preparar un diagrama de flujo de procesamiento para un caso de uso importante, como preparación para el ejercicio de implementación de la próxima semana.
■ Vista previa de la próxima semana: Implementar casos de uso de toda la app (integración)
La próxima semana conectaremos el DAO y la capa de servicio con la UI real (Web/CLI),
y pasaremos a ejercicios de implementación para ensamblar la aplicación como un “sistema que funciona” por caso de uso.
La Semana 36 fue una semana intensa de experimentar el puente que va de “diseño → BD → implementación”.
El alumnado empezó a entender la arquitectura real de aplicaciones y se está preparando, paso a paso,
para la siguiente fase: la “integración de casos de uso”.