Organizzazione dell’applicazione

La Solution

La Soluzione sopra visualizzata è un esempio di organizzazione dell’applicazione che consente una corretta suddivisione logica.

La soluzione è divisa in 5 progetti.

È necessario configurare l’avvio multiplo: prima il progetto API e dopo il progetto UI.

I progetti

1. Api

   

   È il progetto che avvia il sito delle REST Api.
   Contiene i Controllers, lo Startup e l’appsettings.

2. ComponentsLibrary

   contiene l’integrazione con OpenStreetmap, pensata per diventare un package NuGet

3. Data

   DbContext e Repositories (con relative interfaccie) per il recupero e aggiornamento dei dati

4. Shared

   modelli dati (comprese data annotations per validazione)

5. UI

   

   a. Components
   componenti ad uso dell’interfaccia (modali)

   b. Pages
   le pagine con i relativi Code Behind

   c. Interfaces
   interfaccie ai servizi

   d. Services
   servizi per recupero dati via API

   e.Shared
   NavMenu e MainLayout

Analisi

API e Data

L’organizzazione corretta di un progetto può unificare Api e Data all’interno di un’unico progetto chiamato Api.

Mantenere separati i progetti ha senso se in prospettiva si pensa di utilizzare un’altra forma di fruizione dei dati oltre alla Rest API.
Potrebbe essere un ragionamento interessante in funzione di avere una fruizione via GraphQL.
Da valutare progetto per progetto.

Progetto	Dipende da
Data	Shared
Api	Data, Shared

ComponentsLibrary

La ComponentsLibrary potrebbe essere un’idea interessante, ma solamente per aree fortemente trasversali.
L’esempio della mappa via OpenStreet è una buona idea.

Progetto	Dipende da
ComponentsLibrary	nessuno

Shared

Il progetto Shared accentra modelli dati e validazioni.
Normalmente mantengo separate le validazioni per ottimizzare i View Model.
Qui è meglio mantenere solamente i modelli dati, senza validazioni.

Progetto	Dipende da
Shared	nessuno

UI

La UI è correttamente separata.

Progetto	Dipende da
Data	Shared, ComponentsLibrary