Archives mensuelles: mai 2010

4 articles

LINQ to XML et la lecture des très gros fichiers

LINQ to XML est relativement facile à implémenter pour lire de gros fichiers et pour requêter des fichiers XML.
Par exemple, considérons ce fichier XML :

    <?xml version="1.0" encoding="utf-8" ?>
    <users>
        <user name="User1" groupid="4" />
        <user name="User2" groupid="1" />
        <user name="User3" groupid="3" />
        <user name="User4" groupid="1" />
        <user name="User5" groupid="1" />
        <user name="User6" groupid="2" />
        <user name="User7" groupid="1" />
    </users>

Supposons que vous souhaitez trouver tous les enregistrements avec groupid > 2. Vous pouvez être tenté d’implémenter la requête suivante :

    XElement doc = XElement.Load("users.xml");
    var users = from u in doc.Elements("user")
                where u.Attribute("groupid") != null &&
                int.Parse(u.Attribute("groupid").Value) > 2
                select u;
    Console.WriteLine("{0} users match query", users.Count());

Il y a un piège dans cette implémentation. La méthode XElement.Load va lire tout le fichier XML en mémoire avant de s’exécuter, et ce fichier peut être très gros.

Poursuivre la lecture

Méthodes dynamiques (classe DynamicMethod) en .NET

Utiliser la réflexion pour invoquer des méthodes non connues à la compilation peut être problématique en terme de performances dans des applications critiques. L’exécution de ces méthodes est environ 2,5 à 3 fois plus lente qu’un appel directe.
Voici un exemple :

    class Program
    {
        [DllImport("kernel32.dll")]
        static extern void QueryPerformanceCounter(ref long ticks);

        static PropertyInfo _intProp = typeof(Foo).GetProperty("IntProp", BindingFlags.Public | BindingFlags.Instance);

        static void Main(string[] args)
        {
            Foo foo = new Foo { IntProp = 10 };
            const int COUNT = 1;
            Console.WriteLine(Measure(() => ReadPropertyWithReflection(foo), COUNT));
            Console.WriteLine(Measure(() => ReadPropertyDirectly(foo), COUNT));
        }

        static void ReadPropertyWithReflection(Foo foo)
        {
            int intProp = (int)_intProp.GetValue(foo, null);
        }

        static void ReadPropertyDirectly(Foo foo)
        {
            int intProp = foo.IntProp;
        }

        static long Measure(Action action, int count)
        {
            long startTicks = 0;
            QueryPerformanceCounter(ref startTicks);
            for (int i = 0; i < count; i++)
            {
                action();
            }
            long endTicks = 0;
            QueryPerformanceCounter(ref endTicks);
            return endTicks - startTicks;
        }

        class Foo
        {
            public int IntProp { get; set; }
        }
    }

Et voici les résultats :

Type d’accès unités CPU
Invocation par accès directe 796
Invocation par Réflexion 1986

Ainsi, l’utilisation de la réflexion pour lire une propriété est 2,5 fois plus lente que l’accès directe à cette propriété.

Les méthodes dynamiques peuvent être utilisées pour générer et exécuter une méthode à l’exécution sans devoir déclarer une assemblie dynamique et un type dynamique qui contiendront la méthode. Elles représentent un moyen plus efficace pour générer et exécuter ce type de code.

Poursuivre la lecture

Transactional NTFS (partie 1/2)

Transactional NTFS et DotNet

Microsoft introduit un concept intéressant à partir des versions de Windows Vista et Server 2008.
Cette nouveauté est appelée Transactional NTFS (TxF).
Elle permet aux développeurs d’écrire des fonctions d’Entrée/Sortie garantissant le succès complet ou le rejet complet en cas d’erreur d’un ensemble d’opérations.

Malheureusement il n’existe pas de classe DotNet(au moins jusqu’à la version 3.5 SP1) permettant de manipuler simplement ce type d’opérations.

Pour manipuler ces opérations, nous avons besoin de passer par le P/Invoke pour utiliser ces fonctions :

CreateTransaction, CommitTransaction, RollbackTransaction et DeleteFileTransacted

Poursuivre la lecture

Comment nous faisons de l’ASP.NET MVC

Sample MVC Solution

In this post I will show a sample ASP.NET MVC 2.0 project structure illustrating different concepts such as data access, user input validation and mapping between the domain and the view model. The project is still under construction but the source code is available at github.

I will illustrate the usage of the following frameworks:

  • MvcContrib bringing useful extension methods and strongly typed helpers to ASP.NET MVC
  • AutoMapper enabling easy mapping between the domain and the view models
  • FluentValidation – a small validation library for .NET that uses a fluent interface and lambda expressions for building validation rules for your business objects
  • NHibernate – a popular ORM in the .NET world
  • FluentNHibernate – a statically compiled alternative to NHibernate’s standard hbm xml mapping
  • Spring.NET – object container and dependency Injection framework for .NET
  • Rhino.Mocks – A dynamic mock object framework for the .Net platform. It’s purpose is to ease testing by allowing the developer to create mock implementations of custom objects and verify the interactions using unit testing

 

Armed with this arsenal of frameworks let’s start exploring the solution structure. I’ve opted for 2 projects solution but in many real world applications more levels of abstraction could be brought to the business layer. Personally I favor to have less big assemblies rather than many small assemblies into the solution. Fewer the assemblies, faster the load time and faster the IDE. In this case particular attention should be brought to bring proper separation of concerns inside the same assembly

 

ASP.Net MVC project structure

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Poursuivre la lecture