Maurizio's blog 3.0

Negli ultimi tempi mi è capitato spesso di lavorare su applicazioni che utilizzano Oracle come database piuttosto che Sql Server e, naturalmente, ho dovuto utilizzare nello strato di accesso ai dati le classi specifiche di Oracle, meglio note come Oracle Data Provider for .NET. Utilizzare queste classi significa avere a che fare con oggetti tipici di Oracle, es. gli Oracle data type, o i cursori utilizzati per contenere i resultset derivanti da una chiamata ad una store procedure, ecc.

Non avendo una esperienza significativa in Oracle ho sempre pensato che il supporto per .NET fosse alquanto limitato e ridotto all’essenziale,  es.  aprire una connessione ed eseguire un comando SQL che ritorna un resultset.  Ma noto con piacere che mi sbagliavo. La versione 11.1.0.6.20 dell’ODP for .NET fornisce sia una integrazione con l’ambiente Visual Studio  in versione 2005/2008, es. Server Explorer, wizards e designer, sia una integrazione con la piattaforma ASP .NET. Quest’ultima per me è la più interessante in quanto è possibile utilizzare alcuni providers  (argomento di cui ho già parlato in un mio articolo apparso sul sito dello user group DotNetSide) ed utilizzare come repository un database Oracle. Nello specifico i providers sono i seguenti:

• Memberhip (gestione degli utenti e validazione)
• Role (ruoli)
• SiteMap (mappa del sito)
• SessionState (  la Sessione di una applicazione ASP .NET )
• Profile (profili degli utenti)
• Web Event (informazioni circa lo “stato di salute” delle applicazione ASP .NET)
• Web Part personalization (chi lavora con le WebParts può ora memorizzare le informazioni di personalizzazione in un db Oracle)
• Cache Dependency

Il supporto per il Cache Dependency Provider a mio avviso è il più interessante di tutti. Ho già avuto modo di utilizzare ed apprezzare questo meccanismo (invalidazione automatica di un oggetto in cache a fronte di modifiche apportate a resultset memorizzati in un database mediante il meccanismo di notifica) su applicazioni basate su database SqlServer. Sarà sicuramente interessante e produttivo poterlo utilizzare anche in quei contesti dove il database è Oracle.

Ho provato SourceMonitor, un interessante tool freeware per effettuare metriche sul codice sorgente scritto in vari linguaggi di programmazione, tra cui C#, C, C++, VB .NET, Delphi.

Attraverso una interfaccia di gestione molto semplice acquisisce una serie di informazioni, le metriche appunto, analizzando il codice sorgente di un progetto. Queste informazioni possono essere salvate in diversi momenti e nominate (checkpoints), onde poter mettere a confronto metriche di uno stesso progetto create in momenti diversi.

Analizzare le metriche del proprio codice aiuta ad evidenziare eventuali colli di bottiglia, ovvero parti dello stesso da sottoporre a code review, e a migliorare quindi la qualità del codice scritto.

Ecco un elenco delle metriche a mio avviso più importanti:

-% delle linee di codice commentate rispetto al totale delle linee di codice presenti in un file;
-Numero delle classi, interfacce o strutture definite in un file;
-Numero medio di metodi per classe, interfaccia o struttura;
-Valore di complessità per tutti i metodi, ovvero numero totale dei diversi percorsi di esecuzione che ogni metodo  possiede (maggiore è questo valore, più “complesso” è il metodo). Questo valore si puo’ ottenere sia per singolo  metodo, sia come media della complessità di tutti i metodi presenti.

Come detto, analizzare le metriche del codice può aiutare a scrivere codice di qualità, e quindi ad essere uno sviluppatore migliore.

Da .NET 2.0 in poi è possibile terminare un processo corrotto irreparabilmente attraverso il medodo Environment.Failfast(string message), il quale provvede a:

1. Scrivere una entry nell’Application Event Log con il messaggio specificato
2. NON eseguire alcun blocco try-finally ancora in sospeso
3. NON esegue alcun finalizer sugli oggetti ancora in memoria
4. Esegue un dump dell’applicazione
5. Termina il processo

I punti 2-3 sono necessari in un contesto simile in quanto la loro esecuzione potrebbe danneggiare risorse usate dall’applicazione stessa. Tuttavia gli oggetti CriticalFinalizerObject (di cui magari parlerò in un post a parte) sono comunque eseguiti prima di terminare il processo.

Oramai le attenzioni degli sviluppatori sono concentrate sull’accoppiata Windows Vista e .NET Framework 3.0, con tutte le tecnologie annesse che non sto ad elencare. Approfitto di questo post dell’amico Mighell del nuovo user group del sud Italia dotNetSide  (a proposito, complimenti per l’iniziativa e per quanto fatto sinora !), per mettere nel mio blog il riferimento necessario ai vari link per il download del .NET Framework 3.0 RC1. Buon download a tutti !