Catégorie : C#

Par définition, un DTO (Data Transfer Object) permet l’échange de données à travers différentes couche logicielles d’une application. À titre d’exemple, un DTO permet de représenter par une structure de données l’information qui va provenir de votre base de données. L’utilisation est au coeur même du principe qui permet d’écrire du code réutilisable et facilement maintenable.

Tuple, c’est quoi ça?

Un Tuple ou même n-uplet en français est une structure de données permettant de regrouper des types hétérogènes ensemble. Pour ceux plus familier avec l’aspect mathématique de la chose, un Tuple est le concept de Couple étendu à N types.

Avec .NET, il y a huit variations de la classe Tuple. Chacune des variations a son nom qui la distingue :

• Tuple<T1> : Singleton
• Tuple<T1, T2> : Couple
• Tuple<T1, T2, T3> : Triplet
• Tuple<T1, T2, T3, T4> : Quadruplet
• Tuple<T1, T2, T3, T4, T5> : Quintuplet
• Tuple<T1, T2, T3, T4, T5, T6> : Sextuplet
• Tuple<T1, T2, T3, T4, T5, T6, T7> : Heptuplet
• Tuple<T1, T2, T3, T4, T5, T6, T7, T8> : Octuplet

Le concept proposé

Mon but initial lorsque j’ai lu à propos de Tuple serait de savoir s’il serait réellement pratique de l’utiliser avec ExpandoObject pour transporter un certain nombre de données.

Avec la venue de la classe ExpandoObject dans .NET4, il est possible d’ajouter dynamiquement des propriétés à un objet. L’idée m’est venue de tenter de combiner, le temps d’un essai, de combiner ExpandoObject et Tuple ensemble.

Le concept que j’ai développé est disponible pour consultation sur GitHub. Il y a deux méthodes qui sont à regarder : TupleExemple.(Tuple<string, string, string, int, Image> user) et UserRepository.GetRegisteredUserList(). De plus, l’appel à ces deux méthodes est fait dans le constructeur de TupleExemple.

Le constat

Initialement, lorsque j’ai pondu ce code, j’ai été sur l’impression d’avoir trouvé une nouvelle façon d’écrire du code. Mon impression était, qu’avec un nombre limité de propriétés à transporter, un Tuple serait un excellent moyen de transport. Le seul facteur qui me permettait d’affirmer cela est que, dans ce cas-ci, je n’aurais pas à eu besoin de recourir à une classe servant de DTO.

Après relecture de ParseUserInformations, je crois qu’il faut utiliser beaucoup de jugement lorsqu’il est temps d’utiliser un Tuple pour exposer une structure de données qui sera au cœur de votre application. Sur 50 lignes de code, il est facile de se souvenir qu’Item3 est relié au courriel. Toutefois, qu’en sera-t-il lorsque vous tenterez de le faire la même chose avec 10 000 lignes de code?

À mon avis, un scénario idéal pour utiliser Tuple, serait dans le cadre d’opérations très ciblés ayant un contexte précis. Ce que j’ai souvent en tête, c’est une classe en charge de l’importation d’une liste d’utilisateurs dans votre base de données.

Le but serait d’avoir, au sein de la même classe ou méthode, tout ce qu’il faut pour récupérer la source de données originale. Soit la représenter avec un Tuple, faire les transformations nécessaires et l’importer dans votre base de données.

Il faut du recul pour se donner de la perspective sur le chemin qui a été parcouru dans les dernières années. En tant que développeur, il est force d’admettre que les choses évoluent dramatiquement rapidement.

Du côté de .NET, vous vous souvenez de l’époque de .NET 1.1? Comparé à ce qui est possible de faire aujourd’hui, il est à se demander comment il était même possible d’arriver à développer avec ce Framework là!

De mémoire, vous vous souvenez ce qui vous a marqué le plus avec la version 2.0 de .NET? Est-ce que ce serait l’un des points suivants ?

Providers

• Membership
• Role
• Sitemap
• Profile
• Session
• Web events
• Web Parts

ASP.NET Code behind

/app_code ?

Generics?

ASP.NET Thèmes et skins ou même les Master Pages ?

Classes partielles

Itérateurs?

Non!

Pour moi, l’amélioration la plus marquante a été String.IsNullOrEmpty() aura été celle que j’utilise le plus dans tout le Framework. Elle fait, dans une très grande majorité de cas, partie de la première validation sur l’état d’une string lorsqu’on la reçoit en paramètre.

Son implémentation est très simple. Par son nom, il est très facile de déterminer son but : Est-ce que cette chaîne de caractères est de type null ou vide?

Sommairement, cette fonction permet de convertir le code suivant :

var isValid = (maString== null || maString.Length == 0);

de cette façon :

var isValid =  (string.IsNullOrEmpty(maString));

Un hommage

À la blague, j’ai même démarré avec la collaboration d’un ami un micro-blogue en hommage à String.IsNullOrEmpty(). Un billet que j’aime particulièrement est l‘internationalisation de String.IsNullOrEmpty(). L’article met en lumière qu’il n’est quand même pas si simple d’écrire cette même validation en Javascript.

La validation poussée à son maximum

Lorsque j’ai eu à chercher des idées pour ce billet, j’ai trouvé le gist suivant sur Github (note : ne pas faire lire aux enfants) :

https://gist.github.com/1583796

Élégant, clair, très expressif et surtout vulgaire. Adorable! Pourquoi faire simple lorsqu’on peut littéralement inclure la totalité des validations de String dans la même fonction?

Conclusion

Je vais l’avouer, mon affection envers String.IsNullOrEmpty est légèrement démesurée.

Toutefois, à quand revient le dernier moment où vous avez écrit une validation pour déterminer si votre String était null ou vide à l’ancienne? Probablement que ça date de l’instant où vous avez découvert que la fonction existait.

Si vous êtes arrivés sur le billet et que vous venez d’apprendre l’existence même de cette fonction, je crois alors que ma mission de prêcher la bonne nouvelle aura été accomplie!

Lorsqu’il est venu le temps du choix de choisir le moyen de stocker les données de son application, le temps est à la mode de délaisser les bases de données relationnelles pour leur équivalent NoSQL.

Dans le monde .NET, il est possible d’utiliser des technologies comme MongoDB ou même RavenDB qui est de plus en plus populaire chez les programmeurs.

Une base données NoSQL comme RavenDB ne convient pas nécessairement à tous les scénarios de développement. Qu’en est-il de ceux qui désirent utiliser une base de données SQL? Est-ce qu’il y a des alternatives à l’utilisation de la classe SqlCommand?

Pour ces scénarios, j’ai arrêté mon choix à deux candidats qui font leur marque en utilisant deux approches différentes. Tout en ayant comme but de faciliter l’accès à vos bases de données.

Massive

Massive est une librairie développée par le très populaire Rob Conery. Cette librairie se vend comme l’outil vous permettant de résoudre la majorité de vos besoins d’accès de données avec un seul fichier de 673 lignes.

La simplicité de conception de Massive.cs est son principal atout. Il suffit d’intégrer le fichier source à votre application et vous serez en affaires. Notez qu’il vous faut une Connection string de proprement configurée à votre application.

Tel que décrit par son créateur, il faut concevoir Massive comme un Wrapper vous permettant d’accéder à vos données SQL. Son design vise une approche rapide sans dépendances pour accéder à vos donnés

Son utilisation est très simple et par les exemples disponibles sur la page d’accueil du projet GitHub permettent d’emblée de constater que Massive est conçu autour des dynamics ajoutés dans .NET 4.0.

Par exemple, il est possible de faire des requêtes à votre base de données en demandant à Massive de deviner vos intentions par convention.

Cette requête va retourner, sous une liste d’éléments, le résultat de la colonne ProductName de la table Products appartenant au CategoryID 4.

Selon la documentation, en plus de pouvoir faire des requêtes directes à vos données, vous pouvez arriver à :

• Insérer et mettre à jour vos données
• Requêtes utilisant une syntaxe à arguments nommés
• Aggrégation de données en utilisant des arguments nommés avec les fonctions :
  • Min
  • Max
  • Sum
  • Avg
  • Count
• Support pour questionner les schéma de vos données. Par exemple, l’identification du type de données de vos colonnes.
• Validations qui vous permettent d’interrompre une requête lorsque les données ne sont pas à votre goût.
• Événements générés par les actions d’insertion, mise à jour et suppression.

Il est possible d’utiliser Massive avec les bases de données suivantes :

• SQL Server
• Oracle
• PostgreSQL
• Sqlite

Simple.Data

Simple.Data se présente comme outil d’accès aux données dynamique ayant des fonctionnalités retrouvées dans un ORM plus classique.

Tout comme Massive, la composante dynamic de .NET 4.0 est au cœur de l’architecture de Simple.Data. Les requêtes que le développeur va construire seront décodées par convention afin d’y extraire les actions ainsi que les informations qui y sont désirées.

Simple.Data se veut comme un langage dédié (Un DSL pour ceux qui sont plus familiers avec l’anglais). Les requêtes sont, d’une certaines façon, paraphrasées en mots et interprétées par la librairie au moment de l’exécution.  À titre d’exemple, une requête permettant de retrouver un utilisateur par son identifiant courriel serait la suivante : Database.Open().Users.FindByEmail(email);.

Simple.Data support une un vaste éventail de plateformes. Autant des bases de données relationnelles traditionnelles que des bases de données NoSQL. Voici la liste :

• SQL Server 2005 et plus (incluant SQL Azure)
• SQL Server Compact 4.0
• Oracle
• MySQL 4.0 et plus
• SQLite
• PostgreSQL
• SQLAnywhere
• Informix
• MongoDB
• OData

Du point de vue des fonctionnalités, Simple.Data est assez complet et permet d’effectuer une gamme assez vaste de commandes et d’opérateurs vous permettant d’accéder à vos données. Bien entendu, l’insertion, la mise à jour ainsi que la suppression de données est permise.

D’ailleurs, sa nature dynamique permet à Simple.Data d’être un candidat de choix pour faire des tests unitaires. Un adaptateur de données uniquement en mémoire permettant de faire des requêtes sans avoir à accéder à une base de données réelle.

Conclusion

Les deux librairies ne sont pas réellement en compétition l’une envers l’autre. À mon avis, elles répondent à un besoin bien spécifique selon le genre d’opérations que vous désirez compléter.

Massive me semble pratique lorsqu’il est temps d’accéder à rapidement à des données sans trop se soucier de la réutilisation ou de l’architecture de votre couche d’accès aux données. On voit souvent cette application dans un contexte de preuve de concept.

Simple.Data se veut comme une alternative à un ORM que vous pouvez utiliser à toutes les sauces dans votre système lorsqu’il est temps de gérer l’accès à vos données. On remarque cette tendance par le soucis de testabilité de Simple.Data.