Récemment en faisant des recherches sur les possibilités de quelques ORM, je suis tombé par hasard sur un site qui vaut vraiment le coup d’oeil : ORMBattle. La plupart des ORM connus sont testés et comparés entre eux (même s’il en manque, ils sont déjà à l’étude pour passer au peigne fin par l’auteur du site).

Lien : http://www.ormbattle.net/

En développement, il existe une multitude de possibilités d’une opération pour arriver au même résultat final. Outre la « technicité » du développement, le critère des performances est un élément important à prendre en compte. La meilleure mesure dans ce cas est celle du temps.

Avec le Framework .NET, il existe la classe Stopwatch. Cette classe, existante depuis la version 2 du Framework et présente dans l’espace de nom « System.Diagnostics », permet de mesurer l’intervalle de temps effectuée par une ou plusieurs opérations données. Son utilisation est très simple, et sa précision est de l’ordre de la microseconde.

Sa mise en place est très simple, dans l’exemple suivant, on affiche l’intervalle écoulé pour l’exécution du code entre stopWatch.Start() et stopWatch.Stop(), c'est-à-dire l’instanciation de la variable List et l’exécution de la boucle for :

Stopwatch stopWatch = new Stopwatch();  
stopWatch.Start(); // Démarre le chronomètre  
              
List<int> list = new List<int>();  
             
for (int i = 0; i < 100000; i++)  
{  
   list.Add(i);  
}  
              
stopWatch.Stop(); // Arrête le chronomètre  
              
// On affiche le résultat en milliseconds, pour une meilleure lisibilité  
Trace.WriteLine("Temps écoulé (ms) : " + stopWatch.Elapsed.TotalMilliseconds);

Temps écoulé (ms) : 449.0187

Note : nous pouvons aussi le déclarer différemment, avec le mot-clef var par exemple (après ça revient uniquement sur un choix de lecture et de clarté :-))

var stopWatch = Stopwatch.StartNew();

Nous pouvons aussi arrêter le chronomètre, et la reprendre par la suite, si l’on veut calculer un intervalle précis ; bien sûr, même après l’arrêt, le chronomètre garde en mémoire la valeur sur laquelle il s’est arrêté.

Par exemple, nous calculons le temps d’exécution de Method1(), puis on arrête la chronomètre pour exécuter autre chose, puis on le redémarre pour calculer le temps d’exécution de Method2() :

Stopwatch stopWatch = new Stopwatch();  
stopWatch.Start();  
Method1();  
stopWatch.Stop();  
   
List<int> list = new List<int>();  
  
for (int i = 0; i < 100000; i++)  
{  
   list.Add(i);  
}  
   
stopWatch.Start(); // On redémarre le chronomètre  
Method2();  
stopWatch.Stop();  
   
Trace.WriteLine("Temps écoulé (ms) : " + stopWatch.Elapsed.TotalMilliseconds);

Temps écoulé (ms) : 718.0647

Note : nous pouvons aussi calculer en “ticks”. Un tick (qu’on peut traduire par graduation – MSDN) représente une graduation pour X nanosecondes. Pour X, il dépends de votre matériel. Pour le calculer, il existe Stopwatch.Frequency qui nous donne la fréquence correcte.

var watch = Stopwatch.StartNew();

watch.Start();
string str = "1000";
try
{
    int value = int.Parse(str);
}
catch (Exception e)
{
    Console.WriteLine(e.Message);
}
watch.Stop();

Console.WriteLine("Frequence : " + Stopwatch.Frequency);
Console.WriteLine((1e6 * watch.ElapsedTicks / (double)Stopwatch.Frequency) 
                   + " Microsecondes");
Console.WriteLine((1000 * watch.ElapsedTicks / (double)Stopwatch.Frequency) 
                   + " Millisecondes");
Console.WriteLine(watch.ElapsedMilliseconds + " Millisecondes (Stopwatch)");

Console.Read();

Malgré le fait que les machines sont aujourd’hui de plus en plus puissantes, il est toujours utile de faire un audit des performances de son code pendant un développement, cela peut nous aider à prendre certaines décisions que l’ont n’aurait pas prises sans mesure de performance.

Plus d’informations : lien vers MSDN

1) Définition du design pattern Singleton

Le singleton est un design pattern (pour les plus francophone un « patron de conception ») qui consiste à restreindre l'instanciation d'une classe à un seul objet (ou à quelques objets).

Dans la pratique, le singleton peut être utilisé dans le cas d’une classe de connexion à une base de données. Le singleton permet de s’assurer qu’une seule instance de la classe connexion est utilisée.

Par contre, attention à ne pas confondre classe statique et Singleton : les deux sont différents et ne s’appliquent pas dans les mêmes cas. Singleton permet d’utiliser un vrai objet, être hérité (classe « normale »)… etc, la classe statique non (ce qui peut être gênant, dans le cas cité plus haut, dans initialisation de la classe).

Ce design pattern est très pratique, à manipuler selon ses besoins, mais attention à l’utilisation de ce pattern en cas de multithreading : il faut éviter que deux threads accèdent en même temps à la création de l’instance de l’objet. Aussi, certains pensent que c’est un antipattern, du fait qu’on le retrouve « dans tout et n’importe quoi ».

Nous allons donc voir son implémentation avec .NET.

 
2) Exemples d’implémentation C# (thread-safe)

a. Exemple simple

public sealed class MyClass
{
    private static MyClass _instance = null;
    private static readonly object _lock = new object();

    private MyClass()
    {
       
    }

    public static MyClass Instance
    {
        get
        {
            lock(_lock)
            {
                if (_instance==null)
                {
                    _instance = new MyClass();
                }
                return _instance;
            }
        }
    }
}

Le bout de code ci-dessus suffirait à la plupart des cas. Mais dans un contexte multithread, il se peut que nous rencontrerions un problème : les deux threads pourraient arriver au même moment dans la section critique. Dans ce cas, l’instance sera crée deux fois et risque de poser problème.

Pour remédier à ce problème, il existe le Double Checked Locking (verrouillage à double test).

b. Double Checked Locking

Comme dit précédemment, le Double Checked Locking va permettre de rendre notre code plus sécurisé dans un contexte multithread. On va vérifier par deux fois si l’instance n’a pas été crée, pour éviter que deux threads le fasse au « même moment » (comme ça peut arriver dans l’exemple a).

public sealed class MyClass
{
    static MyClass _instance = null;
    static readonly object _lock = new object();
                
    private MyClass()
    {     
    }

    public static MyClass Instance
    {
        get
        {
            if (_instance == null)
            {
                lock (_lock)
                {
                    if (_instance == null)
                    {
                        _instance = new MyClass();
                    }
                }
            }
            return _instance;
        }
    }
}

public sealed class MyClass
{
    private static readonly MyClass _instance = new MyClass();
    
    private MyClass()
    {
    }
        
    public static MyClass Instance
    {
        get
        {
            return _instance;
        }
    }
 }

Pour un projet personnel, j’avais besoin d’utiliser WMI. En recherchant par hasard sur le site de Microsoft, je suis tombé par hasard sur WMI Code Creator. L’outil date de 2005, un peu déçu de ne pas l’avoir découvert plus tôt ! 
 

Lien de téléchargement : http://www.microsoft.com/downloads/details.aspx?FamilyID=2cc30a64-ea15-4661-8da4-55bbc145c30e&DisplayLang=en
Bon téléchargement ;-).

Après la sortie de la beta 1 de Visual Studio 2010 le 18 mai pour les abonnés MSDN, c’est aujourd’hui que la sortie publique aura lieu.

Un des grands changement visible au premier coup d’œil, c’est la nouvelle interface en WPF. Pour les nouveautés en détail, vous pouvez vous rendre sur cette page.