Contenido verificado asociado a este RA
Fundamentos de la Programación Orientada a Componentes y su Entorno
Esta unidad introduce la programación orientada a componentes (POC), valorando sus ventajas y desventajas en el desarrollo de software. Se identifican las características esenciales de un componente y las herramientas de desarrollo clave para su creación y gestión.
Acceso a Datos Persistentes: Ficheros y Bases de Datos Relacionales
Esta unidad aborda la programación de componentes para la gestión de información persistente, cubriendo tanto el almacenamiento en ficheros como la interacción con bases de datos relacionales mediante conectores estándar.
Componentes con Mapeo Objeto-Relacional (ORM) y alternativas: bases de datos objeto-relacionales, orientadas a objetos y XML nativo
Esta unidad se centra en programar componentes que gestionan información mediante Mapeo Objeto-Relacional (ORM), mostrando un ejemplo completo de componente CRUD con JPA/Hibernate. Como contexto complementario, se presentan también las bases de datos objeto-relacionales, orientadas a objetos y nativas XML, con ejemplos de componentes de acceso a cada una, para que el alumnado compare enfoques de persistencia distintos al modelo puramente relacional.
Pruebas, Documentación e Integración de Componentes de Acceso a Datos
Esta unidad se centra en las fases finales del ciclo de vida de un componente: las pruebas exhaustivas para asegurar su correcto funcionamiento, la documentación adecuada para facilitar su uso y mantenimiento, y su integración efectiva en aplicaciones más grandes.
Conceptos clave
Componente de softwareReusabilidadEncapsulaciónInterfazAcoplamientoCohesiónIDEControl de versionesGestor de dependenciasPersistencia de datosFicheros de textoCSVJSONXMLSerialización/DeserializaciónJDBCADO.NETConectores de base de datos
Errores que conviene evitar
- Confundir una clase con un componente: Una clase es una plantilla para objetos, mientras que un componente es una unidad de software autocontenida y desplegable que puede estar compuesta por varias clases. Corrección: Un componente debe tener una interfaz bien definida, ser autocontenido y reutilizable en diferentes contextos, no solo una clase aislada.
- Ignorar la gestión de dependencias: No usar un gestor de dependencias puede llevar a conflictos de versiones (DLL Hell en .NET, Jar Hell en Java) o a la falta de librerías necesarias. Corrección: Integrar Maven, Gradle o NuGet desde el inicio del proyecto para declarar y resolver dependencias de forma automática y consistente.
- No cerrar recursos (ficheros, conexiones DB): Esto puede llevar a fugas de memoria, bloqueos de ficheros o agotamiento de conexiones a la base de datos. Corrección: Utilizar bloques `try-with-resources` en Java o sentencias `using` en C# para asegurar el cierre automático de los recursos, o cerrar explícitamente en bloques `finally`.
- Inyección SQL: Construir consultas SQL concatenando cadenas directamente con la entrada del usuario. Corrección: Usar `PreparedStatement` en JDBC o `SqlCommand` con parámetros en ADO.NET para evitar la inyección SQL, ya que los parámetros se envían por separado de la consulta.
- Problemas de rendimiento con ORM (N+1 selects, carga perezosa mal gestionada): un uso ingenuo del ORM puede generar muchas consultas pequeñas en vez de una consulta optimizada. Corrección: entender cómo el ORM traduce las operaciones a SQL, elegir estrategias de carga adecuadas (eager/lazy) según el caso y recurrir a consultas nativas o proyecciones (DTOs) cuando el mapeo automático no sea eficiente.
- Ignorar el esquema en bases de datos XML: aunque son flexibles, no definir una estructura esperada para los documentos puede provocar inconsistencias difíciles de consultar. Corrección: usar XML Schema (XSD) o DTD para validar los documentos antes de insertarlos, facilitando consultas XQuery consistentes.
- Confundir 'no necesito SQL' con 'no necesito entender el modelo de datos': usar un ORM no exime de diseñar bien las entidades y sus relaciones; un mal diseño de entidades genera consultas ineficientes independientemente de la herramienta usada.
- Falta de cobertura de pruebas: No probar todos los escenarios (casos límite, errores) del componente de acceso a datos. Corrección: Diseñar pruebas que cubran el 100% de las ramas de código importantes, incluyendo escenarios de éxito, error, datos nulos y volúmenes grandes.