PartiteWeb

Contesto

Progetto del corso di Programmazione Web all’Università di Trento. PartiteWeb è il servizio backend di MatchWeb: si occupa della parte relativa alle partite ed espone le API REST che l’applicazione principale consuma.

Sono tre endpoint soltanto — il calendario completo, le partite di una giornata, i risultati di una giornata — ma sono il contratto su cui io e il mio compagno di corso ci siamo accordati per poter lavorare sulle due applicazioni in parallelo. Questa metà l’ho scritta io.

Il dominio

Il modello ruota attorno a tre entità:

• Partita — l’incontro, con data, squadre coinvolte e sport di riferimento
• Squadra — le formazioni iscritte
• Sport — la disciplina, che determina le regole di composizione del calendario

Sopra questo modello sta un servizio dedicato alla generazione del calendario degli incontri.

Scelte tecniche

Ho usato JDBC con JdbcTemplate e un RowMapper scritto a mano invece di un ORM. Su uno schema di tre tabelle, JPA avrebbe aggiunto un livello di astrazione — e di comportamenti impliciti, dal lazy loading alle sessioni — senza risparmiare codice in modo significativo. Scrivere le query esplicitamente ha reso chiaro cosa arriva davvero al database.

Lo schema e i dati di partenza vivono in schema.sql e data.sql, così l’ambiente si ricrea da zero a ogni avvio: comodo per un progetto che gira su H2 in memoria e che deve poter essere clonato ed eseguito senza configurazione.

Cosa ne ho tratto

La parte più istruttiva non è stata scrivere gli endpoint, ma decidere dove tracciare il confine tra questo servizio e il resto dell’applicazione: cosa espone, cosa tiene per sé, e quanto del proprio modello lascia trapelare fuori.