Eccomi qui pronto di nuovo a postare.
L'argomento, che tratterò in una serie di post, è il nuovo Borland Developer
Studio 2006, uno
splendido strumento per lo sviluppo Win32 e dotNET.
In questa serie, mi focalizzerò sullo sviluppo dotNET, in particolare una
nuovissima e molto promettente tecnologia di nome Enterprise Core
Objects ver. III(abbreviato ECOIII).
Essa è basata(per ora) su dotNET 1.1 SP1, poiché BDS 2006 non supporta dotNET
2.0(previsto invece per la prossima versione) e consente di avere un completo
motore di persistenza e di gestione di oggetti.
BDS2K6 viene in tre edizioni diverse: Pro, Enterprise, Architect. Ognuna di
esse ha un "pezzo" di ECO, tranne la Architect che ha invece
*tutto*.
Vediamo come funziona ECO "concettualmente": l'idea è basata sul Model Driven
Development, infatti allo scopo BDS2K6 include Together, un tool di modellazione
Borland anche per Visual Studio. Esso viene esteso da ECO per supportare la
modellazione di classi persistenti, quindi si ha a disposizione un insieme di
elementi UML da utilizzare per la pianificazione e la modellazione del
sistema-applicazione.
Quando servirà poi definire il sistema di persistenza, ecco che ECO mostra i
muscoli: nelle versioni Enterprise ed Architect, infatti, è disponibile un
completo framework che consente di avere indipendenza dal sistema database
utilizzato(sono supportati tutti i DB attraverso i Borland Data Provider, di cui
parlerò più avanti) e consente anche - in caso di cambio al modello - di
evolvere il database.
La funzione di evoluzione è anche utile quando si ha un database preesistente
e si vuole generare il modello(opzione disponibile), aggiungendo quindi al DB
tutti i campi e le robe che servono ad ECO per
funzionare in modo
corretto.
Come detto, però, ECO non è solo un motore di persistenza: è infatti
disponibile un Object Control Language(OCL) tramite il quale definire, vincoli,
constraints, ma anche operazioni(supponendo ad
esempio di voler caricare
tutti gli elementi di classe TPersona, lo statement OCL è
semplicemente
"TPersona.AllInstances").
Tra i vari metodi di serializzazione disponibili, ovviamente, c'è anche il
formato XML, specificatamente SOAP - molto utile se si sviluppano Webservices
oppure se si scrivono applicazioni "desktop".
E non è finita qui 
Dicevo che avrei parlato dei Borland Data Provider più avanti... beh, spero
che la piccola introduzione abbia suscitato un minimo di interesse, quindi ecco
una piccola descrizione di cosa sono.
Posto in termini semplici, la tecnologia BDP si appoggia alla
"infrastruttura" ADO.NET aggiungendo
però un pò di cose: anzitutto, c'è un
sistema di connection pooling built-in(cosa che fa molto
comodo in certi
ambiti) e poi... uhm... mi sa che se continuo così, questo post non finisce più
,
quindi vi rimando a questo articolo introduttivo sui BDP.
Ah, ovviamente ECO supporta anche ASP.NET 1.1(versioni ENT e ARCH), quindi
potete creare dei "Webservice ECO" i quali sono quindi già "mezzi pronti", basta
solo aggiungere il codice.
Si, parlo di codice, infatti ECOIII non è un C.A.S.E.: pur potendo modellare
le classi da rendere persistenti, si possono aggiungere delle operazioni(metodi)
e codarle "a manina" mentre ECO si occupa di tutto il resto(persistenza,
distruzione, ecc).
Sfortunatamente, io dispongo solo della versione PRO, per di più da pochi
giorni, quindi sto ancora imparando "bene" come realizzare i modelli e le vere
potenzialità della tecnologia.
Una cosa però è degna di menzione: l'edizione Architect, oltre ad una
serie di "goodies" in generale(troppa roba per elencarla in un post) contiene
una parte di ECO molto interessante: è infatti possibile realizzare
delle "ECO State Machines" che consentono di realizzare delle macchine a stati
da usare con le classi persistenti. Molto, molto, molto carino .
Per ora finisco qui, spero di tornare presto con un altro post ed un pò di
codice per mostrare come nella pratica funziona ECOIII(quindi anche con un pò di
codice).
Saluti,
Andrea