Criterios y estructura propuesta para los proyectos

Este documento propone criterios verificables de estructura, nomenclatura y responsabilidades para los proyectos de Java de segundo semestre y de React Native con Expo de cuarto semestre, de acuerdo con la referencia Estructuras ValleGrande. Los árboles muestran una estructura objetivo; no afirman que el código actual ya la cumpla.

Criterios comunes

La guía de código limpio exige identificadores en inglés en todos los semestres: nombres de clases, métodos, variables, archivos y paquetes. El texto visible al usuario y la explicación del README pueden estar en español. Se debe usar un solo idioma para los identificadores, incluso en el modelo de base de datos.

Cada clase y función debe tener una responsabilidad reconocible. La guía considera ideal una función de hasta 15 líneas y aceptable una de 16 a 30; también pide evitar duplicación, números sin nombre y capturas genéricas de errores. El criterio práctico es que un cambio de interfaz no obligue a modificar consultas SQL y que un cambio de base de datos no obligue a reescribir la vista.

1. Java de segundo semestre

La referencia establece Java 17 o superior, interfaz Swing, MySQL y JDBC. El proyecto actual utiliza JavaFX y conserva los libros en memoria. La migración de la interfaz debe confirmarse con el docente antes de implementarla. Los nombres del árbol toman Book como entidad de ejemplo.

library/
├── .gitignore
├── README.md
├── pom.xml
├── database/
│   └── schema.sql
└── src/
    ├── main/
    │   └── java/
    │       └── pe/edu/vallegrande/library/
    │           ├── Main.java
    │           ├── view/
    │           │   ├── BookCrudView.java
    │           │   └── BookEditView.java
    │           ├── controller/
    │           │   └── BookCrudController.java
    │           ├── service/
    │           │   └── BookService.java
    │           ├── dto/
    │           │   └── BookDto.java
    │           ├── model/
    │           │   └── Book.java
    │           ├── dao/
    │           │   └── BookDAO.java
    │           ├── db/
    │           │   └── AccessDB.java
    │           ├── util/
    │           └── exception/
    └── test/
        └── java/
            └── pe/edu/vallegrande/library/
                └── BookServiceTest.java

Relación entre capas: View → Controller → Service → DAO → AccessDB → MySQL.

• view presenta los datos y recibe las acciones del usuario.
• controller coordina la vista y llama al servicio.
• service valida datos y aplica reglas del sistema.
• dao ejecuta las operaciones de datos mediante JDBC.
• db/AccessDB.java centraliza la conexión con MySQL.
• database/schema.sql define las tablas necesarias.
• test contiene pruebas de la lógica del servicio.

Cambios principales desde el proyecto actual: configurar Java 17 o superior; sustituir el almacenamiento en memoria por JDBC y MySQL; renombrar Libro como Book y LibroDAO como BookDAO; mover el DAO fuera de model; agregar la capa service; hacer que el controlador utilice el servicio; completar el README y las pruebas. Si el docente exige Swing, reemplazar la vista JavaFX. El nombre de proyecto library es provisional porque los documentos de referencia muestran convenciones distintas para el uso de guiones en proyectos Java.

Criterios de revisión para Java

• El proyecto compila con la versión de Java declarada.
• Las clases, métodos, campos, paquetes y tablas tienen nombres descriptivos en inglés.
• La vista no ejecuta SQL ni contiene reglas de negocio.
• El controlador depende de BookService, nunca de BookDAO o AccessDB.
• BookService valida y coordina las operaciones; BookDAO realiza el acceso a datos.
• AccessDB centraliza la conexión; las credenciales se obtienen de configuración local, sin subirlas al repositorio.
• Existen pruebas de las reglas del servicio y un README con instrucciones reproducibles.

2. Aplicación móvil de cuarto semestre

El proyecto disponible es una aplicación Expo y React Native, por lo que corresponde al estándar móvil de cuarto semestre. La guía usa el prefijo vg-app- y TypeScript. library es solo un nombre de ejemplo; debe reemplazarse por el nombre real del proyecto.

vg-app-library/
├── .gitignore
├── README.md
├── app.json
├── package.json
├── tsconfig.json
├── app/
│   ├── _layout.tsx
│   ├── +not-found.tsx
│   ├── (tabs)/
│   │   ├── _layout.tsx
│   │   ├── index.tsx
│   │   └── settings.tsx
│   └── books/
│       ├── index.tsx
│       └── [id].tsx
├── components/
│   ├── ui/
│   │   ├── Button.tsx
│   │   └── Input.tsx
│   └── books/
│       ├── BookCard.tsx
│       └── BookForm.tsx
├── services/
│   ├── api.ts
│   └── bookService.ts
├── hooks/
│   └── useBooks.ts
├── types/
│   └── book.types.ts
├── constants/
│   └── Colors.ts
└── assets/

Relación entre carpetas: app → components y hooks → services → API; los contratos de datos se guardan en types.

• app contiene únicamente las pantallas y los archivos de navegación de Expo Router.
• components reúne elementos visuales reutilizables y componentes propios de cada función.
• services centraliza las solicitudes HTTP mediante Axios.
• hooks concentra la lógica reutilizable de las pantallas.
• types define los tipos de datos de TypeScript.
• constants guarda valores compartidos, como los colores.

Cambios principales desde el proyecto actual: conservar una sola carpeta app/ y retirar la duplicación con src/app/; reunir los componentes y utilidades en una ubicación coherente; actualizar los imports; usar el prefijo vg-app-; completar el README. La guía incluye Axios, NativeWind y React Hook Form. Su incorporación debe hacerse con versiones compatibles con el SDK de Expo instalado. El proyecto ya tiene Expo Router, AsyncStorage y strict: true.

Criterios de revisión para Expo

• Solo hay una carpeta de rutas de Expo Router y cada archivo de ruta representa una pantalla.
• Las pantallas coordinan componentes y hooks; no contienen solicitudes HTTP ni lógica de almacenamiento repetida.
• bookService.ts concentra las llamadas a la API y api.ts configura el cliente Axios.
• Los componentes visuales no conocen las URL de la API.
• Los tipos de datos están definidos en types/ y TypeScript conserva strict: true.
• Archivos, componentes, funciones, rutas y variables usan nombres descriptivos en inglés.
• Los formularios tienen validación y los estados de carga y error son visibles para el usuario.
• El README explica cómo instalar, configurar y ejecutar la aplicación.

Referencias

• Tecnologías por semestre
• Estructuras de proyecto
• Código limpio
• Patrones de arquitectura