Skip to content.
Logo tecnoteca

Portale Tecnoteca.it

Logo tecnoteca

Vai al sito aziendale Tecnoteca.com


 
You are here: tecnoteca.it » Sezioni speciali » Linguaggi ed ambienti » Delphi » Architettura

Argomenti correlati:
  - Approfondimento

Architettura

L’architettura per l’accesso alle basi dati


Oltre alla scelta di quale strumento avvalersi per l’accesso ai dati (Bde, Ado ecc.) bisogna decidere il tipo di applicazione che si intende sviluppare: quello a livello singolo, quello a due livelli (o client/server) e quello a tre livelli (Three-tier).

Il primo approccio, livello singolo, è quello legato all’utilizzo di database semplici (cosiddetti Flat, quali per esempio Paradox, Dbase o Access) nel quale il database è visto solo come un insieme di dati salvati su disco ed a cui si accede tramite funzioni la cui logica è completamente insita nel programma che richiede i dati stessi. In questo caso si parla in genere di applicazioni database ad un livello.

Il secondo approccio è quello così detto
Client/Server (o a due livelli). In questo caso il database (tipicamente relazionale) è un vero e proprio programma che si occupa di salvare in un proprio formato i dati e che permette l’accesso a questi dati tramite chiamate a sue funzioni. Ormai è divenuto uno standard l’utilizzo di un vero e proprio linguaggio di interrogazione delle basi dati (SQL Structured Query Language) attraverso il quale un qualsiasi programma invia delle richieste di dati al database e questi risponde fornendo i risultati. Si configura quindi una situazione in cui ci sono uno o più programmi (Client) che richiedono dati al programma che gestisce la base dati (Database Server). Tutto il lavoro di accesso ai dati è quindi svolto dal Server (che tipicamente risiede su una macchina dedicata esclusivamente a questo scopo) mentre il programma Client si limita ad inviare semplici richieste di dati e ad attendere il risultato.

Il terzo approccio è quello cosiddetto del three-tier, ovvero a tre livelli (in generale l’n-tier, cioè a n livelli). In questo caso infatti i computer client non si connettono direttamente al database server bensì ad uno (o più) Application server. Sarà poi l’application server ad interrogare il database server per ottenere i dati necessari al client. Ovviamente se l’application server (cioè il livello intermedio tra la richiesta di dati ed i dati stessi) facesse solamente da tramite tra client e server non si avrebbe nessun vantaggio rispetto ad un approccio client/server tradizionale, anzi, si avrebbe semplicemente un sovraccarico di lavoro sulla macchina dove risiede l’application server ed un allungamento dei tempi di risposta sui client. Il grosso vantaggio di questo approccio è che diventa possibile spostare tutta la “logica di utilizzo dei dati” e “l’effettivo accesso al db” dal client all’application server, mantenendo sul client la sola capacità di iterazione con l’utente (interfaccia grafica).



 

Client/Server, perchè?


In un ambiente distribuito, dove piu’ utenti hanno la necessità di avere accesso agli stessi dati, il modello a livello singolo, e quindi l’uso di database di tipo flat (Paradox, Access, Dbase ecc..), risulta essere non piu’ sufficiente per vari motivi. Per prima cosa infatti la necessità di elaborare tutti i dati in locale sul computer di ogni utente implica un grosso traffico di rete ed un generale decadimento delle prestazioni. In secondo luogo non è possibile disporre di tutti quegli strumenti offerti dai database RDBMS per il salvataggio, la manutenzione ed il controllo centralizzato dei dati.
L’architettura client/server è nata quindi per sopperire a queste grosse limitazioni. In questa architettura il database è in grado di elaborare le richieste fatte dai client (tipicamente queste sono query SQL), in modo ottimizzato, ritornando a questi ultimi solo i risultati (viene così minimizzata la quantità di dati che viaggia sulla rete). Un database server inoltre permette la gestione di basi dati di maggiori dimensioni. Si occupa, in modo automatico, della gestione degli accessi contemporanei e concorrenti ai dati e permette di utilizzare meccanismi di protezione e di sicurezza piu’ evoluti e potenti.
Per capire che cosa è e come funziona il linguaggio Sql si puo’ consultare, tra gli altri, il seguente tutorial (in inglese).



 

MIDAS e l'n-tier


L’architettura client/server si è sviluppata principalmente per sopperire alle difficoltà di gestione delle basi dati flat in ambienti distribuiti e con più utenti . Allo stesso modo lo sviluppo di applicazioni a più livelli può intendersi come un’evoluzione del modello Client/Server. Il modello di sviluppo a tre livelli prevede la creazione di un programma (l'application server) che si situa tra il database server vero e proprio ed i vari client. A questo punto i client non colloquiano piu' direttamente con il database server ma piuttosto con l'application server. Tipicamente sull'application server viene quindi trasferita tutta la parte di gestione e manipolazione dei dati che prima veniva fatta sul client. Così a questo si demanda la sola capacità di iterazione con l'utente.
I maggiori vantaggi offerti da una architettura di questo tipo sono:
1) Tutti gli accessi alla base dati avvengono solo dall'Application Server, che può quindi facilmente ususfruire di una linea veloce di accesso al database server e quindi permette di ottenere delle ottime performance (soprattutto se i client fossero costretti ad usare una linea lenta per il collegamento con il database server, ad esempio una Wan).
2) Si mantiene tutta la logica di accesso ai dati (le così dette Business Rules) concentrata nell’Application Server
3) Si favorisce lo sviluppo di applicativi Client di dimensioni inferiori (thin Client)

Delphi possiede dei componenti che facilitano lo sviluppo di applicazioni a tre e più livelli. Questi componenti sfruttano una tecnologia chiamata MIDAS, che consiste sostanzialmente in un meccanismo automatico, particolarmente efficiente, per il passaggio automatico di dati tra il client e l’application server. In pratica MIDAS si occupa di instradare i dati (suddivisi in “pacchetti” chiamati datapacket) ad alcuni componenti che si occupano del trasferimento vero e proprio di questi tra l’application server ed i client.