DotNetCampania
Il primo portale campano dedicato allo sviluppo software con tecnologie Microsoft

Progetto GeRi – Parte 3

100% of people found this useful
Progetto GeRi – Parte 3

Il terzo articolo di questa miniserie sullo sviluppo di un applicativo “enterprise” verterà sull’architettura dell’applicativo.

The Architecture – L’Architettura
GeRi è una piattaforma software che nasce con lo scopo di gestire tutte le attività, dirette e indirette, connesse ad una centro assistenza.
Analizziamo di seguito alcune scelte di tipo architetturale, prima di passare direttamente alla fase di design dell’applicativo.

SOA - Service Oriented Application
.
Come è stato evidenziato nei precedenti articoli, la nostra piattaforma deve essere in grado di “agganciarsi” a servizi di fornitori esterni per espletare alcune operazioni.
Un esempio su tutti è la necessità di inviare messaggi SMS.
Ma oltre ad usufruire di servizi esterni, la nostra piattaforma deve essere anche in grado di erogare servizi, acquisendo e garantendo quindi un certo grado di flessibilità con il mondo dell’integrazione.
Erogare/esporre servizi, significa anche permettere facilmente a sistemi esterni (magari realizzati con linguaggi e tecnologie differenti) in prima istanza di dialogare con il nostro sistema, e in seconda istanza di implementare moduli di integrazione con la nostra piattaforma.
Ad esempio non è da ritenersi rara la possibilità di “integrazione” del nostro sistema con sistemi di fatturazione di terze parti.
Per questo motivo ritengo valido scegliere un’architettura di tipo SOA ovvero “Orientata ai Servizi”.

Architectural View
Applicazione N-TierAvendo ben chiaro il contesto architetturale nel quale intendiamo realizzare la nostra applicazione, analizziamo di seguito alcune scelte su come organizzare l’architettura dell’applicativo.

L’applicazione sarà organizzata secondo una classica architettura di tipo N-Tier.
Ma cos’è un applicazione N-Tier?
Una architettura di tipo N-Tier indica una particolare architettura software che prevede la suddivisione del sistema in N diversi livelli (logici e fisici) che svolgono funzionalità diverse (opzionalmente su nodi diversi della rete).
Ad esempio esiste il livello per la gestione dell’interfaccia utente (UI Layer), quello per la logica funzionale (Business Layer) e quello per la gestione della persistenza dei dati (Data Access Layer).
In questo modo, ciascuno degli N livelli può essere modificato o sostituito indipendentemente dagli altri.
Nella maggior parte dei casi, si intende anche che i diversi livelli siano distribuiti su diversi nodi di una rete anche eterogenea.
Questo è alla base della distinzione tra Layer e Tier.

  • Un Layer indica un raggruppamento logico delle funzionalità
  • Un Tier indica un raggruppamento fisico delle funzionalità

Un esempio tipico di architettura N-Tier, dove N=3, detta appunto three-tier prevede, per esempio:

  1. un Tier di presentazione identificato da un PC dedicato all'interfaccia utente grafica (su cui persiste quindi il layer di presentazione o UI Layer)
  2. un Tier di Business Logic indentificato da una workstation o un application server per l’esecuzione di business logic
  3. un Tier di Database indentificato da un database server o un mainframe per la gestione dei dati.

In merito alla nostra applicazione avremo quindi i seguenti Layers :

  1. Data Access Layer (da ora in poi DAL) è il livello di interazione con la base di dati, dove si effettuano le connessioni e si eseguono query di selezione, inserimento, aggiornamento o cancellazione.
  2. Business Layer (da ora in poi BL) è il livello che ha la responsabilità di gestire le richieste utente ricevute attraverso l’Uil o SL, di effettuare il routing di queste richieste agli appropriati elementi di business, di processare i risultati dell'elaborazione e ritornare i dati necessari all’Uil o SL per la successiva presentazione all'utente.
  3. Service Layer (da ora in poi SL) è il livello che svolge la funzione di “collante” tra il BL e l’UiL ed è caratterizzato da un numero di servizi che espongono al “mondo esterno” le funzionalità business.
  4. User Interface Layer (da ora in poi UiL) è il livello che si occupa della presentazione e della logica di interazione con l'utente, interagendo con il BL per l'accesso ai servizi richiesti.

Organizzati nei seguenti Tiers :

  1. Database Tier, ovvero il livello fisico su cui deployeremo il nostro Database.
  2. Application Server Tier, ovvero il livello fisico su cui deployeremo il BL e il SL.
  3. Presentation Tier, ovvero il livello fisico su cui deployeremo l’interfaccia grafica della nostra applicazione.

Ritengo concluso il terzo articolo della serie, che è servito a delineare l’aspetto architetturale su cui si fonda la soluzione da implementare.
Scopo del prossimo articolo sarà quello di “creare gli use cases” e quindi "disegnare il nostro Core".
Non mi resta quindi che finire con il classico :
Idea See u in the next episode Idea

(Fonte : Alessandro Forte - http://www.alessandroforte.it/)

Recent Comments

Leave the first comment for this page.

Associazione Culturale DotNetCampania - C.F.: 95127870632

Powered by Community Server (Commercial Edition), by Telligent Systems