\section{Problematiche riscontrate}
\subsection{Persistenza}
L'utilizzo della \gls{jpa} introduce un livello di astrazione che permette di gestire in modo semplice le interazioni tra applicazione e \gls{db}, portando in termini di produttività enormi vantaggi. Questa tuttavia è un'arma a doppio taglio, poiché un uso errato può causare problemi prestazionali estremamente lesivi per l'esperienza utente. Un aspetto critico riguarda la scelta della strategia di prelievo delle informazioni dalla base di dati. Sono fornite dalla classe \texttt{javax.persistence.FetchType} due strategie differenti: \texttt{AEGER} e \texttt{LAZY}. La strategia \texttt{AEGER} comporta il caricamento di tutti i dati relativi all'entità selezionata, compresi quelli addizionali. \texttt{LAZY} implica l'esclusione dei dati relazionati.

Date le premesse, diventa di vitale importanza scegliere la giusta strategia da adottare in relazione all'uso che faremo del dato prelevato.

Supponiamo di avere a disposizione due classi A e B legate da una relazione uno-a-molti da A verso B. Se il modello imponesse una strategia di caricamento AEGER, l'esecuzione di una query di selezione comporterebbe il caricamento di A unito alla lista di elementi di tipo B relazionati. Questo scenario soffre di tempi di caricamento addizionali nel caso in cui non si abbia la necessità di reperire anche i dati relazionati.

Un secondo scenario considera la situazione precedentemente descritta applicando una strategia di caricamento \texttt{LAZY}. In questa situazione il prelievo delle informazioni relazionate ad A porterebbe al problema \texttt{(N + 1) SELECT} \cite{NPONE}. Come possiamo vedere dal Codice \ref{lst:nplusoneproblem} sono necessarie due fasi per reperire i dati:
\begin{enumerate}
    \item Riga 1: viene prelevata la lista di oggetti di tipo A. I dati relazionati non sono presenti al loro interno.
    \item Riga 2-5: si itera sugli oggetti prelevati al passo precedente e, mediante il metodo getter della property specifica, si carica il dataset relativo dei dati relazionati. Il sistema esegue una query SELECT per ognuno degli elementi piuttosto che reperire le informazione desiderate con una singola operazione.
\end{enumerate}

\input{code_24_nplusoneproblem.tex}

Sarà cura del programmatore studiare i casi specifici ed imporre all'interno delle relazioni la strategia giusta per minimizzare i tempi di caricamento.

\subsection{Interfaccia Utente}
Le problematiche maggiori riguardano la transizione delle viste tabellari da dispositivi desktop a mobile. Dato l'elevato numero di colonne e la lunghezza variabile delle informazioni contenute nelle celle, si è scelto di gestire le righe di una tabella mediante l'integrazione grafica di blocchi di dati contigui sottesi da uno header di colore blu che permetta la separazione logica dei dati. Mostriamo il risultato di tale elaborazione grafica in figura \ref{fig:mobile_view}.

\begin{figure}[!h]
    \centering
    \frame{\includegraphics[origin=c,width=0.5\textwidth]{img/MOBILE_VIEW.png}}
    \caption{Vista tabellare su dispositivo mobile}
    \label{fig:mobile_view}
\end{figure}

L'obiettivo finale è quello di raggiungere la piena compatibilità con tutte le classi di dispositivi attualmente sul mercato.