Dependency Injection con Ninject

Riprendendo il post introduttivo alla dependency injection, sono numerosi i pacchetti in nuget che consentono di creare injection in maniera semplice. Ninject è un dependency injector open-source per .NET e vanta un numero piuttosto cosistente di scaricamenti ed installazioni.  Alcuni dei punti di forza che vengono enfatizzati dal team di sviluppo sono la semplicità e la facilità di utilizzo.

Nello sviluppo di applicazioni Web, in particolare MVC, l’utilizzo di un dependency injector consente di realizzare velocemente soluzioni “switchando” tra repository differenti. Questo significa che è possibile realizzare applicazioni con dati “demo” facilmente testabili e successivamente passare ai dati in produzione.

Continua a leggere Dependency Injection con Ninject

Introduzione alla dependency injection

Dependency Injection (DI) e Inversion Of Control (IoC) sono due elementi fondamentali per lo sviluppo di applicazioni “moderne”. A prima vista possono sembrare due concetti complessi ma, una volta appresi i principi, difficilmente si potrà farne a meno.

Il problema da risolvere è la dipendenza tra oggetti

Continua a leggere Introduzione alla dependency injection

Design Patterns

I design patterns sono un’elemento fondamentale per lo sviluppo di architetture software complesse. Durante le fasi della progettazione, prima della fase di scrittura, è importante porre l’attenzione sulla riusabilità o meglio sulla possibilità di riutilizzare lo stesso codice all’interno della stessa soluzione ma anche in progetti diversi.

Riutilizzare codice all’interno dello stesso progetto, ma anche in nuovi progetti

Le architetture software, sviluppate ad oggetti e ben strutturate, sono composte da pattern. Una delle metriche utilizzabili per valutare la qualità di un software potrebbe essere proprio l’attenzione posta dagli sviluppatori nel riutilizzo del codice e l’applicazione di pattern.
Continua a leggere Design Patterns

Programmazione Asincrona e deadlock

Nel refactoring di applicazioni windows form (ebbene si, esistono ancora!) o comunque in quelle applicazioni con lunghi task di elaborazione, uno dei problemi di maggiore impatto per gli utenti è il freeze dell’interfaccia utente.

A partire dal framework 4.5 (C# 5) sono disponibili  le keyword async e await per la scrittura di codice asincrono.  Una delle funzionalità che può essere sfruttata a partire da questa versione (al momento della scrittura di questo articolo è disponibile la release 7.2, ma per questioni legacy non posso upgradare l’applicazione oltre la versione 5.0) è il TAP (Task Async Pattern) .

Task Async Pattern

Utilizzando TAP con async/await è possibile scrivere codice asincrono in maniera semplice senza perdere in potenza. Il seguente metodo consente di eseguire in forma asincrona un metodo (MyMethod) che non lo è.

Per poter ottenere il risultato dell’elaborazione del metodo MyMethodAsync possiamo utilizzare il seguente codice:

L’utilizzo di questo codice all’interno di una console application funziona correttamente. Nel caso in cui la nostra applicazione sia GUI/ASP il risultato è un deadlock. L’esecuzione dovrà essere terminata utilizzando il task manager. 

I metodi asincroni dovrebbe prevenire il blocco delle applicazioni, ma non è sempre così.

Leggendo un pò di documentazione online, ho risolto il problema utilizzando il metodo ConfigureAwait. Questo metodo consente di effettuare l’await del Task su cui stiamo effettuando la configurazione. L’utilizzo del parametro booleano continueOnCapturedContext e dovrà essere impostato a true nel caso in cui sia necessario attendere il ritorno dal context catturato, oppure false nel caso non sia necessario. L’esempio che generava il deadlock può essere rescritto nel seguente modo:

L’utilizzo del metodo ConfigureAwait con continueOnCapturedContext impostato a false consente di risolvere il problema di deadlock.

Novità in C# 7.2

Dopo il rilascio di C# 7.1, è stato pubblicato l’aggiornamento C# 7.2 che porta con se alcune modifiche abbastanza significative alla major release 7.0. Nel seguito di questo articolo analizzeremo le più importanti.

Digital separator after base specifier

Una delle principali novità introdotte in C# 7.0 è la possibilità di definire il separatore numerico attraverso il simbolo _ (underscore). Questa nuova sintassi consente di rendere più leggibile il codice quando si ha a che fare con numeri e formati. Inoltre consente di rappresentare in modo più semplice numeri di grande dimensione. Ad esempio, il seguente codice

consente di rappresentare rispettivamente un numero decimale, un numero esadecimale e un numero binario. Da notare che il formato è rappresentato dal prefisso del numero, ovvero 1, 0x e 0b.

In C# 7.2 è possibile posizionare il carattere underscore dopo la definizione del tipo. Il codice precedente può essere rappresentato nel modo seguente:

Non-trailing Named Arguments

C# dalla versione 4.0 è stato il primo linguaggio di programmazione a permettere il passaggio di parametri, con nome, ai metodi. Questo tipo di approccio consente di utilizzare parametri opzionali, facendo in modo che il compilatore non generi un errore durante il riconoscimento dei parametri.

Il seguente metodo:

definisce tre parametri, assegnando un nome al secondo e al terzo. Il modo più semplice, ma anche quello meno leggibile, per richiamare il metodo è il seguente:

Per rendere il metodo più comprensibile può essere utilizzata la seguente sintassi:

e scambiando l’ordine dei parametri:

Una limitazione era rappresentata dall’impossibilità di far seguire ad un parametro con nome, un parametro posizionale. In C# 7.2, il problema viene superato, ed è possibile compilare codice del tipo:

Private Protected

Fino alla versione 7.1 di C# erano disponibili i seguenti modificatori di accesso:

  • public : non sono presenti limitazioni nell’accesso;
  • protected: l’accesso è limitato alla classe o ai tipi derivati della classe che li contiene
  • internal: l’accesso è consentito solo nell’assembly corrente
  • private: l’accesso è consentito solo al contenitore
  • protected internal: l’accesso è limitato all’assembly corrente o i tipi derivati dalla classe di appartenenza.

A partire dalla versione 7.2 è stato introdotto un nuovo modificatore: private protected.

L’introduzione di questo nuovo modificare consente di limitare l’accesso a una classe o i tipi derivati dalla classe di appartenenza all’interno dell’assembly corrente.

Un membro dichiarato private protect non è accessibile per la classe derivata se è dichiarata all’esterno dell’assembly corrente.

Con questa nuova funzionalità il numero totale di modificatori di accesso sale a sei.

Un membro dichiarato private protect non è accessibile all’interno dell’assembly per le classi che non ereditano dalla classe in cui è dichiarato.

 Ref readonly

L’introduzione di questa nuova funzionalità può essere considerata come l’opposto delle variabili con la keyword out.  Le variabili utilizzate come parametro di un metodo con la keyword ref sono passate per riferimento. Una modifica all’interno del metodo, viene riportata all’esterno del metodo stesso. Le variabili utilizzate come parametro di un metodo con la keyword out possono essere utilizzate solo per ritornare un valore (output) e non come input.

Dichiarando un parametro di un metodo come readonly ref il parametro viene passato al metodo e cercando di modificarne il valore, il compilatore segnalerà un errore in quanto non modificabile. Allo stesso modo, passando un parametro out ad un metodo dovrà essere valorizzato prima di poter essere ritornato. Utilizzando insieme parametri readonly ref e out possiamo creare metodi che accettano in ingresso variabili non modificabili per riferimento e variabili che devono essere valorizzate prima che il metodo termini il suo normale flusso.