Continuiamo in questa puntata con le speculazioni estive intorno all’argomento del boxing/unboxing e perfomance.

Nel post precedente abbiamo parlato di cosa vogliano dire i termini in oggetto, e abbiamo evidenziate le motivazioni che stanno dietro alle penalità di perfomance proposte per queste attività.

Qui ora acceneremo qualcosa riguardo ai generics.

Uno dei grossi vantaggi introdotti dal mondo “generics” è legato alle perfomance, oltre che la “type safety”.

L’abbiamo già accennato, ma è meglio rispecificare. Con quest’ultimo termine si intendono le attività atte a evitare gli errori derivanti da lavorare con variabili di tipo incerto: la definizione è abbastanza generica, ma sono certo che rende bene l’idea.

Per vedere bene i vantaggi e gli svantaggi vediamo l’utilizzo della classe ArrayList fornita da .Net Framework, e che è una delle poche classi che permette l’utilizzo di object come argomento.

Per i pochi che non lo sanno la classe ArrayList rappresenta un semplice array di object la cui dimensione autonomamente e dinamicamente si adatta ai valori inseriti senza dover fare alcunchè.

Essendo che tutte le variabili in .Net derivano da System.Object, sia direttamente che indirettamente, ecci che quindi object è in grado di ospitare qualisiasi tipo di dato.

Può sembrare una stranezza, ma è proprio così: usando ArrayList è possibile aggiungere a questa un intero, una stringa, un oggetto, o comunque una variabile di qualsiasi tipo ci passi per la testa.

Questa “libertà”, però, ha conseguenze nefaste, se non è ben gestita.

In C# è possibile identificare due tipi di variabili: i value types e i reference types: una qualsiasi variabile che dichiariamo all’interno del codice è mutuamente appartenente a uno dei due tipi citati.

Alla maggior parte dei programmatori questa affermazione non provoca particolare interesse: al massimo può provocare un fragoroso: …. e chi se frega ?? Oppure più mestamente provocare confusi ricordi legati alla prima formazione ricevuta su C#.

Infatti usualmente quando si studia il C# questa differenza viene ben spiegata e approfondita, ma poi avendo implicazioni pratiche molto limitate usualmente “si perde il concetto”.

In effetti il programmatore mediamente può assolutamente disinteressarsi di questa differenza, e considerala micragnosa e petulante, ma quando si hanno esigenze di perfomance….. allora proprio lì si va a finire !

Inoltre…… non è interessante capire come “funziona il giocattolo” ??

Dunque: torniamo ai value types e i reference types.

Quando il programma viene eseguito viene allocato un certo spazio di RAM delegato a contenere i dati necessari per l’esecuzione: all’interno di questo spazio  vengono riservate alcune zone che hanno compiti ben precisi e stabiliti.

Le zone delegate a contenere il valore delle variabili dichiarate all’interno del programma sono due, e sono chiamate managed heap e lo stack.

Come noto in Sql Server le stored procedure possono essere scritte usando codice .Net, tramite l’ausilio della Sql Server CLR Integration.

In questo post esporrò la procedura pratica passo-passo per creare una stored procedure in C#, e utilizzando le funzionalità di Visual Studio 2017 che permettono di raggiungere l’obbiettivo in modo facile e intuitivo.

Quanto scritto vale perfettamente e identicamente (si può dire ?) anche per Visual Studio 2015.

Premessa

Non so Voi, ma a me spesso riesce difficile scrivere alcune stored procedure direttamente in T-SQL: infatto SQL è un linguaggio prettamente dichiarativo, e a volte molte elaborazioni necessarie per estrarre dati richiedono procedure prettamente procedurali.

Linguaggi dichiarativi->Sono linguaggi in cui si descrive il risultato che si vuole ottenere (T-SQL è uno di questi).

Linguaggi Procedurali->Si descrive come ottenere un risultato (C# per esempio).

Ora, come noto T-SQL permette anche di scrivere codice usando lo stile procedurale (vedi cursori, etc), ma per chi, come me, è abituato per il 90 % della sua giornata a usare C# e PHP, e quindi stili di programmazione prettamente procedurali, diventa difficile convincere il cervello a fare lo “switch” a codice dichiarativo.

Per tale motivo per qualche stored procedure particolarmente complessa non disdegno di usare la SQL CLR Integration, e quindi di scrivere stored procedure usando codice C#.

Devo osservare anche usare questo tipo di stored procedure può introdurre anche importanti benefici nelle perfomance: in alcune situazioni i tempi di esecuzione sono sensibilmente più brevi rispetto allo stesso codice scritto in T-Sql.

Fine Premessa (era inutile ??)

Il Common Language Runtime (CLR) è la base fondamentale di Microsoft .NET Framework ed è la parte delegata all’esecuzione di managed code ottentuta da linguaggi compatibili.

Sql Server si integra con il CLR usando la funzionalità CLR integration, che in sostanza si traduce nella possibilità di scrivere diversi elementi procedurali usando managed code, invece di T-Sql.

• Stored procedures
• Triggers
• User-defined functions (UDF)
• User-defined types
• User-defined aggregates