SignalR primi passi: Log viewer in Realtime con Log4Net

Per lavoro ho iniziato a muovere i primi passi con SignalR. SignalR è una libreria che crea una persistent connection tra client e server, permettendo al server di inviare al client dati in modalita push. Crea inoltre un’astrazione sulla modalità di trasporto adottata (periodic polling, long polling & websockets), e fornisce un’unica interfaccia di programmazione.
Ma perche’ utilizzarla?  Un’applicazione necessita del real-time perché ci sono situazioni in cui i dati visualizzati devono essere aggiornati costantemente (in modalita push). Un caso emblematico può essere quello delle quotazioni di borsa. 

Il web è basato sul protocollo HTTP, che per sua natura è request/response. Pertanto, ci troviamo ad utilizzare un protocollo unidirezionale senza stato (ovvero che non permette di fare delle chiamate push server-to-client in maniera nativa). Per utilizzare una modalità push, quindi, dobbiamo ricorrere ad alcuni workaround. Ci sono molti siti ufficiali, blog, tutorial, etc. per documentarsi. Questo e’ solo il mio primo esempio.

La parte di configurazione ed installazione la lascio al sito microsoft…  Il progetto che presentero’ e’ una banale  console per visualizzare log in real time da diverse fonti, in questo caso da diverse webApi.

Ci sono 3 livelli di log (lOG4nET): debug, info, error. In SignalR, ogni livello di log è che sia proprio gruppo.  L’interfaccia utente consente all’utente di passare ogni livello. Ogni livello di log e’ associato ad un’attivita’ di SignalR. L’implementazione finale e’ semplice:  Quando il logger ricerve un messaggio, lo trasmette al gruppo associato. Ogni metodo di log chiama Log(string level, string message):

public void Log(string loglevel, string message)
{

     Log(new LogItem() { Level = loglevel, Message = message });
}
private void Log(LogItem item)
{
     IConnectionManager connectionManager = AspNetHost.DependencyResolver.Resolve<IConnectionManager>();
     dynamic clients = connectionManager.GetClients<LogEndpoint>();
     clients[item.Level].receiveLogEntry(item);
}

L’hub espone 2 metodi: WatchLevel(string) and UnwatchLevel(string) which add the current connection to the group.

public void WatchLevel(string level)
{
     if (LogLevels.Contains(level))
     {
          AddToGroup(level);
     }
}

public void UnwatchLevel(string level)
{
     if (LogLevels.Contains(level))
     {
          RemoveFromGroup(level);
     }
}

Il frontend ha un metodo principale chiamato receiveLogEntry che accetta un LogItem come parametro.
LogItem è un semplice POCO con Timstamp, livello, e proprietà del messaggio.
I nuovi messaggi vengono anteposti alla tabella o aggiunti alla console a seconda della vista.

Quanto detto e’ il funzionamento di base.
Nel progetto ho aggiunto un paio di cose come la codifica a colori dei messaggi di errore
e una semplice scroll automatica ed un elenco di connessioni correnti e di
registrazione semplici in tutta l’applicazione.

Questo e’ un semplice punto di partenza per avere un log centralizzato. A questo link e’ possibile fare il download del
progetto github qui.

Annunci

Select Join ricorsiva in c# con Linq

imagesOggi ho avuto bisogno di creare un extension method per poter selezionare in modo ricorsivo i figli di figli di un item padre in una lista. 🙂

Ecco una soluzione pulita per fare gerarchica ricorsiva join in LINQ e C#. Ho avuto difficolta’ a trovare su internet un esempio, quindi ho deciso di scrivere un post con il mio approccio che fornisce metodi di estensione per IEnumerabe <T> per fare ricorsione:

Prima di tutto la mia struttura gerarchica:
Text | ID | Parent ID
A | 1 | –
B | 2 | –
C | 3 | 1
D | 4 | 1
E | 5 | 2

I dati sono rappresentati dall’oggetto

public class ObjectData
{
   public string Text { get; set; }
   public int Id { get; set; }
   public int ParentId { get; set; }
}

mentre i nodi gerarchici dal seguente oggetto:

public class NodeData
{
 public string Text { get; set; }
 public IEnumerable<NodeData> Children { get; set; }
}

Il nostro obiettivo e’ avere un oggetto gerarchico fatto in questo modo:
A –>
|_ C
|_ D
B —>
|_ E

Usando il mio metodo di estensione RecursiveJoin LINQ, è possibile trasformare i dati (rappresentati da ObjectData) in dati gerarchici (rappresentati da NodeData) come segue:

Prima di tutto creiamo i nostri dati:

ObjectData[] elements = new ObjectData[][]
{
   new ObjectData[]{Id = 1, Text = "A"},
   new ObjectData[]{Id = 2, Text = "B"},
   new ObjectData[]{Id = 3, ParentId = 1, Text = "C"},
   new ObjectData[]{Id = 4, ParentId = 1, Text = "D"},
   new ObjectData[]{Id = 5, ParentId = 2, Text = "E"}
};

E poi implementiamo il RecursiveJoin per creare il nostro oggetto “ricorsivo”

IEnumerable<NodeData> nodes = elements.RecursiveJoin(element => element.Id,
 element => element.ParentId,
 (ObjectData element, IEnumerable<NodeData> children) => new NodeData()
 {
 Text = element.Text,
 Children = children
 });

Ci saranno due root nodi A e B. A avra’ i figli C e D mentre B avra’ come figlio solo E.
L’esempio usa semplicemente la forma del metodo RecursiveJoin con la seguente firma:

public static IEnumerable<TResult> RecursiveJoin<TSource, TKey, TResult>
   (this IEnumerable<TSource> source,
      Func<TSource, TKey> parentKeySelector,
      Func<TSource, TKey> childKeySelector,
      Func<TSource, IEnumerable<TResult>, TResult> resultSelector);

Il codice della classe si puo’ trovare sul mio Github

Print all properties and value of a object in recursive way

imagesSometimes you have the need ‘to print the properties of an object and its values. This is, at least for me, when in debug using a new object and you want to know all his property ‘.
I created these recursive methods that due to reflection I print all the properties and values.
I posted the code on Github.

Understanding Delegates in C#

Basically it is similar like the old “C” age function pointer, where functions can be assigned like a variable and called in the run time based on dynamic conditions. C# delegate is the smarter version of function pointer which helps software architects a lot, specially while utilizing design patterns.

At first, a delegate is defined with a specific signature (return type, parameter type and order etc). To invoke a delegate object, one or more methods are required with the EXACT same signature. A delegate object is first created similar like a class object created. The delegate object will basically hold a reference of a function. The function will then can be called via the delegate object.

Sounds easy? If not lets have a look in the code snippets below.
Continua a leggere

Pattern Singleton

A causa dello sviluppo di un progetto Enterprise, sto utilizzando più volte il pattern Singleton per far fronte alle varie esigenze.
Il pattern Singleton permette allo sviluppatore di creare una, ed una sola istanza di una classe, inibendone la libera istanziazione.
Molti di voi staranno gia pensando il motivo per il quale utilizzare questo pattern.
Elenco dei brevi punti che vi chiariranno sicuramente le idee :

  1. Si ha un’unico accesso controllato alla classe;
  2. Evità di creare variabili globali;
  3. Permette quindi di essere accessibile da qualunque oggetto, nello stato in cui si trova;
  4. Permette di restringere il numero degli oggetti creati.

Passiamo ad un’esempio C# :

public class SingletonClass {

//Campo privato utilizzato dalla proprietà
private static SingletonClass _istanza = null;
//Costruttore privato per rendere la prorpietà Istanza unico punto di accesso
private SingletonClass() { }

//Proprietà di accesso
public static SingletonClass Istanza
{
get
{
if(istanza == null){
istanza = new SingletonClass();
return Istanza;
}
}
}

I pattern Singleton sopra descritto ha pero un problema riguardante gli accessi da parte di più thread contemporaneamente, nello specifico potrebbero essere create due istanze  di SingletoneClass in questa istruzione :

istanza = new SingletonClass();

Risolvere il problema è più semplice di quanto si pensi, basta infatti bloccare l’accesso all’istruzione di istanziazione attraverso lo statement lock (nel caso si utilizzi C#).

Esempio C# :

public class SingletonClass {

//Campo privato utilizzato dalla proprietà
private static SingletonClass _istanza = null;

static readonly object lockObj = new object();
//Costruttore privato per rendere la prorpietà Istanza unico punto di accesso
private SingletonClass() { }

//Proprietà di accesso
public static SingletonClass Istanza
{
get
{
lock(lockObj)
{
if(istanza == null){
istanza = new SingletonClass();
return Istanza;
}
}
}
}

Strategy pattern

Rende intercambiabili un gruppo di algoritmi incapsulandoli per famiglie (Interfacce); questo fa in modo che all’interno della stessa famiglia (Interfaccia) gli algoritmi siano interscambiabili

Essendo un pattern abbastanza semplice da capire pubblico il codice della sua implementazione e lo spiego passo passo
public abstract  class Character
        {
            public IWeaponBehavior Weapon;
            public void ChangeWeapon (IWeaponBehavior newWeapon)
            {
                this.Weapon = newWeapon;
            }

              public abstract void Fight();
        }
        public interface IWeaponBehavior
        {
            void UseWeapon();
        }

Continua a leggere