DEV Community: François Borgies

Le ShouldSerialize Pattern, un pattern à (re-)découvrir ?

François Borgies — Sun, 13 Feb 2022 12:02:35 +0000

Le ShouldSerialize Pattern est une fonctionnalité à utiliser dans le contexte de la sérialisation de
données. Malgré tous les avantages que cette fonctionnalité offre, elle demeure méconnue. Dans cet
article, je vous explique comment en tirer parti et dans quel cadre l’utiliser.

Le ShouldSerialize Pattern permet de résoudre facilement des problèmes que j’ai rencontrés à de
nombreuses reprises. Le gain de temps potentiel est donc un aspect à ne pas négliger. Afin d’être le
plus concret possible, je vous propose un exemple pratique à partir du postulat suivant :

J'ai un objet "Personne" à sérialiser en XML. L'objet sérialisé ne doit contenir la date de décès que si elle existe et par conséquent, ne peut pas être égale à la valeur par défaut d'une DateTime (01/01/0001 00:00:00). Cet objet a la définition suivante :

[XmlRoot("personne", Namespace = Namespace)]
public class Personne {
     [XmlAttribute("nom")]
     public string Nom { get; set; }

     [XmlAttribute("prenom")]
     public string Prenom { get; set; }

     [XmlAttribute("age")]
     public int Age { get; set; }

     [XmlAttribute("dateDeNaissance", DataType = "date")]
     public DateTime DateDeNaissance { get; set; }

     [XmlAttribute("dateDeDeces", DataType = "date")]
     public DateTime DateDeDeces { get; set; }
}

Relativement difficile à résoudre avec une DateTime non-nullable, le pattern ShouldSerialize rend la tâche triviale.

Comment fonctionne-t-il et comment le mettre en place ?

On n'a besoin que d'une chose : une méthode facultative (apparue très rapidement dans les premières versions .Net et semi cachée dans la documentation officielle, d'où le fait sans doute de sa disparition dans les bonnes pratiques de développement) liée aux propriétés et qui permet d'avertir le concepteur, Visual Studio dans mon cas, que la propriété a été modifiée par rapport à sa valeur par défaut et qu'il doit en tenir compte, ou non, lors de la sérialisation.

Reprenons notre objet, dans lequel j'implémente la méthode ShouldSerialize{nom de la propriété}() afin de réaliser la demande business :

[XmlRoot("personne", Namespace = Namespace)]
public class Personne {
     ...

     [XmlAttribute("dateDeDeces", DataType = "date")]
     public DateTime DateDeDeces { get; set; }

     public bool ShouldSerializeDateDeDeces()
     {
         return DateDeDeces != DateTime.MinValue;
     }
}

Une variante plus récente à partir de C# 7.1, moins lisible à mon sens du fait de l'utilisation du littéral "default", mais renforce la maintenabilité du code :

[XmlRoot("personne", Namespace = Namespace)]
public class Personne {
     ...

     [XmlAttribute("dateDeDeces", DataType = "date")]
     public DateTime DateDeDeces { get; set; }

     public bool ShouldSerializeDateDeDeces => DateDeDeces != default;
}

Le littéral "default" permet de spécifier la valeur par défaut (merci La Palice) d'un type donné, lorsque le compilateur peut déduire le type d'expression. Dans ce cas, default = DateTime.MinValue.

Très important dans les deux cas, le nom de la méthode doit commencer par "ShouldSerialize" et être suivi du nom de la propriété visée, "DateDeDeces".

Au moment où la sérialisation XML sera exécutée, la méthode ShouldSerializeDateDeDeces() sera évaluée par le concepteur, si le retour est "true", la propriété sera intégrée dans l'XML résultant, si le retour est "false", elle ne le sera pas.

Les avantages de ce pattern sont :

Sa facilité d'utilisation, d'écriture et de maintenance sur l'ensemble des propriétés d'un objet à sérialiser, en fonction des demandes business (on sait tous que certaines demandes business peuvent être farfelues ou dépendantes de systèmes rigides et historiques).
Sa compatibilité pour la plupart des Serializers (XML, JSON, ...).

Vous l'avez compris, si votre projet requiert de la sérialisation, le ShouldSerialize Pattern doit figurer en bonne place parmi votre arsenal de fonctionnalités. Par conséquent, gardez bien cette fonctionnalité dans un coin de votre tête ! Il existe d'autres patterns / fonctionnalités que je vous invite à explorer afin de résoudre le plus efficacement possible vos problèmes liés à la sérialisation de données.

Happy coding !

EF Core - Tester efficacement vos Repositories avec xUnit et les tests InMemory.

François Borgies — Mon, 23 Nov 2020 09:54:08 +0000

Dans cet article je vous montre comment tester efficacement vos repositories avec des tests unitaires InMemory. je recours régulièrement à cette méthode qui donne d'excellents résultats. Il serait dommage de passer à côté ! Cette méthode, simple et efficace, permet de simplifier les tests et d'éviter des effets de bords indésirables.

Prenons comme exemple la classe User et son repository avec les méthodes de création et de récupération :

public class User(){
    public int Id { get; set; }
    public string Lastname { get; set; }
    public string Firstname { get; set; }
}

public interface IUserRepository(){
    public User Get(int userId);
    public int Post(User user);
}

public class UserRepository(){
    private MyDbContext _context;
    public UserRepository(MyDbContext context){
        _context = context;
    }

    public User Get(int userId){
        return _context.Users.SingleOrDefault(u => u.Id == userId);
    }

    public int Create(User user){
        _context.Users.Add(user);
        _context.SaveChanges();
        return user.Id;
    }
}

Si on souhaite tester unitairement les deux méthodes de ce Repository, il faut Mocker le DbContext et le DbSet.Cette pratique de développement est à éviter. En effet, elle complexifie les tests et, de facto, en diminue l'efficacité et en augmente le coût de maintenance.

Une possibilité serait de mocker les méthodes Get et Create et de définir leur comportement, ce qui rend le test pratiquement inutile, car c'est justement le comportement de ces méthodes que l'on souhaite tester. Une solution simple et efficace est d'utiliser l'approche de la base de données en mémoire, comme le montre le code ci-dessous :

public class UserRepositoryTests(){
    private readonly Fixture _fixture;

    public UserRepositoryTests(){
        _fixture = new Fixture();   
    }

    [Fact]
    public void GetShouldReturnsUser(){
        // Arrange
        var id = _fixture.Create<int>();

        // Ce code permets de simuler une base de données
        // directement en mémoire et de pouvoir interagir
        // avec celle-ci.   
        var options = new DbContextOptionsBuilder<MyDbContext>()
                .UseInMemoryDatabase("TestIMDatabase")
                .Options;

        using (var context = new MyDbContext(options))
        {
            context.Users.Add(new User
            {
                Id = id,
                Lastname = _fixture.Create<string>(),
                Firstname = _fixture.Create<string>(),
            });
            context.SaveChangesAsync();
        }

        // Act && Assert
        using (var context = new MyDbContext(options))
        {
            var sut = new UserRepository(context);
            var user = sut.Get(id);
            Assert.NotNull(user);
        }
    }
}

J'utilise un vrai DbContext, dans lequel j'insère un User que je récupère via ma méthode de Get. Cela permet de tester unitairement le comportement de cette dernière.

Même chose pour la méthode Post :

[Fact]
public void PostShouldAddUser(){
    // Arrange
    var expectedUser = _fixture.Create<User>();
    var options = new DbContextOptionsBuilder<MyDbContext>()
            .UseInMemoryDatabase("TestIMDatabase")
            .Options;

    // Act && Assert
    using (var context = new MyDbContext(options))
    {
        var sut = new UserRepository(context);
        var actualId = sut.Create(user);
        Assert.NotNull(actualId);
         Assert.Equal(actualId, expectedUser.id);
    }
}

Ce genre de test est très pratique quand on souhaite vérifier le comportement des opérations de type CRUD. Elle l'est tout autant lorsque la base de données en elle-même, n'a pas d'incidence pour le test. En effet, la Base de Données en mémoire est uniquement dédiée aux tests car ce n'est pas une réelle Base de Données, elle ne supporte pas les transactions ni les requêtes SQL en directe et bien sûr, n'est pas optimisée pour la performance.

Happy coding !

EF Core - Créer un filtre global sur l'ensemble de vos requêtes.

François Borgies — Fri, 06 Nov 2020 09:46:13 +0000

Dans cet article je vous explique comment définir et configurer, à travers l'exemple de la suppression logique, un filtre sur l'ensemble de vos requêtes Linq.

Avant de rentrer dans le vif du sujet, je vous mets en contexte. Il y a quelques jours, j'ai élaboré un modèle de données qui devait prendre en compte une suppression logique de l'ensemble des entités de ce dernier. J'ai donc naturellement prévu dans le Core de mon application, une classe de base dont héritent directement, ou par transition, les différentes entités de mon modèle :

public abstract class BaseEntity : ISoftDelete
{
    // Implémente ISoftDelete   
    public bool Deleted { get; set; }
}

Une fois mon Core défini et mes différents Mappings EfCore créés, je m'attelle à la réalisation des Repositories et des opérations de CRUD. Mais, une chose me saute aux yeux. Pour chaque requête Linq, je me refuse à écrire ce genre de ligne redondante :

public Blog Get(Guid blogId)
{
    return _ctx.Blogs.FirstOrDefault(b => b.Id.Equals(blogId) && !b.Deleted);
}

Evidemment il est possible de créer un filtre sur l'entité dans la méthode OnModelCreating de votre DbContext :

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>().HasQueryFilter(p => !p.Deleted);
}

C'est une solution viable mais étant donné que je devais l'appliquer à l'ensemble de mes entités, je ne souhaitais pas configurer chaque entité de cette façon. Comment faire alors pour appliquer ce filtre une seule fois et pour l'ensemble des requêtes qui manipulent des entités de mon modèle ?
La réponse est via la réflexion. Je ne vais pas rentrer dans le détail de ce mécanisme très puissant du .Net dans cet article.
Là n'est pas le but. J'invoque donc une méthode de filtre au moment de l'exécution d'une requête sur mon modèle de données. Pour cela j'ai besoin d'une classe d'extension :

internal static class SoftDeleteQueryExtension
{
    internal static void AddSoftDeleteQueryFilter(this IMutableEntityType entityData)
    {
        var methodToCall = typeof(SoftDeleteQueryExtension)
            .GetMethod(nameof(GetSoftDeleteFilter), BindingFlags.NonPublic | BindingFlags.Static)
            .MakeGenericMethod(entityData.ClrType);

        var filter = methodToCall.Invoke(null, new object[] { });

            entityData.SetQueryFilter((LambdaExpression)filter);
     }

     private static LambdaExpression GetSoftDeleteFilter<TEntity>() where TEntity : class, ISoftDelete
     {
         Expression<Func<TEntity, bool>> filter = x => !x.Deleted;
            return filter;
     }

Cette classe appliquera le filtre GetSoftDeleteFilter, chaque fois qu'une requête sera utilisée sur une entité de mon modèle.

Il ne reste plus qu'à configurer mes entités pour bénéficier automatiquement de ce filtre, dans le OnModelCreating :

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
 foreach (var entityType in modelBuilder.Model.GetEntityTypes())
 {      
  if(typeof(ISoftDelete).IsAssignableFrom(entityType.ClrType))
  {
   entityType.AddSoftDeleteQueryFilter();
  }
 }
}

Le code boucle sur chaque entité de mon model, si celle-ci implémente l'interface ISoftDelete, on lui ajoute le filtre.

Votre filtre est prêt ! L'exemple du départ devient donc :

public Blog Get(Guid blogId)
{
    return _ctx.Blogs.FirstOrDefault(b => b.Id.Equals(blogId));
}

Cette requête filtre automatiquement les blogs qui sont supprimés logiquement. En effet, ma classe Blog hérite de BaseEntity qui implémente l'interface ISoftDelete et donc, par transition, Blog implémente également cette interface. Par conséquent au moment où la requête sera exécutée, le filtre sera appelé et appliqué.

En bonus, si vous souhaitez récupérer dans certaines requêtes les entités supprimées logiquement, vous devez utiliser la méthode IgnoreQueryFilters() sur votre requête :

var deletedEntities= _ctx.Blogs.IgnoreQueryFilters()
    .Where(x => x.Deleted)
    .ToList();

Happy Coding !