Panoramica dell'integrazione con CLR

Common Language Runtime (CLR) è il fulcro di Microsoft .NET Framework e fornisce l'ambiente di esecuzione per tutto il codice .NET Framework. Il codice eseguito all'interno di CLR viene definito codice gestito. CLR fornisce varie funzioni e servizi necessari per l'esecuzione del programma, incluse le funzioni di compilazione JIT (Just-In-Time), di allocazione e gestione della memoria, di imposizione dell'indipendenza dai tipi, di gestione delle eccezioni, di gestione dei thread e di sicurezza. Per altre informazioni, vedere .NET Framework SDK.

Con CLR ospitato in Microsoft SQL Server (denominato integrazione CLR), è possibile creare stored procedure, trigger, funzioni definite dall'utente, tipi definiti dall'utente e aggregazioni definite dall'utente nel codice gestito. Poiché il codice gestito viene compilato in codice nativo prima dell'esecuzione, è possibile ottenere aumenti significativi delle prestazioni in alcuni scenari.

Il codice gestito usa la sicurezza dall'accesso di codice (CAS) per impedire agli assembly di eseguire determinate operazioni. SQL Server usa il sito di amministrazione centrale per proteggere il codice gestito e impedire la compromissione del sistema operativo o del server di database.

Vantaggi dell'integrazione con CLR

Transact-SQL è progettato specificamente per l'accesso diretto ai dati e la manipolazione nel database. Sebbene Transact-SQL eccelle nell'accesso ai dati e nella gestione, non è un linguaggio di programmazione completo. Ad esempio, Transact-SQL non supporta matrici, raccolte, cicli for-each, spostamento dei bit o classi. Anche se alcuni di questi costrutti possono essere simulati in Transact-SQL, il codice gestito ha integrato il supporto per questi costrutti. A seconda dello scenario, l'implementazione di determinate caratteristiche del database nel codice gestito può risultare particolarmente vantaggiosa.

Microsoft Visual Basic .NET e Microsoft Visual C# offrono funzionalità orientate agli oggetti, ad esempio incapsulamento, ereditarietà e polimorfismo. Il codice correlato può ora essere organizzato facilmente in classi e spazi dei nomi. Quando si lavora con grandi quantità di codice server, ciò consente di organizzare e gestire più facilmente il codice.

Il codice gestito è più adatto a Transact-SQL per calcoli e logica di esecuzione complicata e offre un ampio supporto per molte attività complesse, tra cui la gestione delle stringhe e le espressioni regolari. Con la funzionalità disponibile nella libreria .NET Framework, è possibile accedere a migliaia di classi e routine predefinite. È possibile accedervi facilmente da qualsiasi stored procedure, trigger o funzione definita dall'utente. La libreria di classi di base (BCL) include classi che forniscono funzionalità per la manipolazione delle stringhe, operazioni matematiche avanzate, accesso ai file, crittografia e altro ancora.

Annotazioni

Anche se molte di queste classi sono disponibili per l'uso dal codice CLR in SQL Server, quelle non appropriate per l'uso lato server (ad esempio, le classi di windowing), non sono disponibili. Per altre informazioni, vedere Librerie .NET Framework supportate.

Uno dei vantaggi del codice gestito è l'indipendenza dai tipi o la garanzia che il codice acceda ai tipi solo con modalità consentite e ben definite. Prima che venga eseguito il codice gestito, CLR verifica che il codice sia sicuro. Ad esempio, il codice viene controllato per assicurarsi che nessuna memoria venga letta che non è stata scritta in precedenza. CLR consente anche di garantire che il codice non manipola la memoria non gestita.

L'integrazione con CLR offre un potenziale miglioramento delle prestazioni. Per informazioni, vedere Prestazioni dell'integrazione con CLR.

Scelta tra Transact-SQL e codice gestito

Quando si scrivono stored procedure, trigger e funzioni definite dall'utente, è necessario decidere se usare Transact-SQL tradizionale o un linguaggio .NET Framework, ad esempio Visual Basic .NET o Visual C#. Usare Transact-SQL quando il codice eseguirà principalmente l'accesso ai dati con logica procedurale o scarsa. Utilizzare codice gestito per le procedure e le funzioni che richiedono un utilizzo elevato della CPU e sono caratterizzate da una logica complessa o quando si desidera utilizzare la libreria di classi di base di .NET Framework.

Scelta tra l'esecuzione nel server e l'esecuzione nel client

Un altro fattore nella decisione relativa all'uso di Transact-SQL o del codice gestito è la posizione in cui risiedere il codice, il computer server o il computer client. Sia Transact-SQL che codice gestito possono essere eseguiti nel server. In questo modo, il codice e i dati si troveranno vicini e sarà possibile usufruire delle capacità di elaborazione del server. D'altra parte, è possibile evitare di inserire attività a elevato utilizzo di processore nel server di database. La maggior parte dei computer client oggi è molto potente e può essere utile sfruttare questa potenza di elaborazione inserendo il maggior numero di codice possibile sul client. Il codice gestito può essere eseguito in un computer client, mentre Transact-SQL non può essere eseguito.

Scelta tra stored procedure estese e codice gestito

Le stored procedure estese possono essere compilate per eseguire funzionalità non possibili con le stored procedure Transact-SQL. Le stored procedure estese possono tuttavia compromettere l'integrità del processo di SQL Server, mentre il codice gestito verificato non può essere indipendente dai tipi. Inoltre, la gestione della memoria, la pianificazione di thread e fibre e i servizi di sincronizzazione sono più profondamente integrati tra il codice gestito di CLR e SQL Server. Con l'integrazione con CLR, è disponibile un modo più sicuro rispetto alle stored procedure estese per scrivere le stored procedure necessarie per eseguire attività non possibili in Transact-SQL. Per altre informazioni sull'integrazione con CLR e sulle stored procedure estese, vedere Prestazioni dell'integrazione con CLR.

Vedere anche

Installazione di .NET Framework
Architettura dell'integrazione con CLR
Accesso ai dati da oggetti di database CLR
Introduzione all'integrazione con CLR