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