Bonne pratique et Astuce : Plug-ins et activités de workflow personnalisées

Dans cet article, j'aimerais vous présenter une des nouvelles fonctions apportées par Microsoft cette fois-ci pas à l'application Microsoft Dynamics CRM mais au fameux IDE Visual Studio 2015 ; il s'agit du nouveau Template de projet "Shared project".

J'imagine que vous vous posez la question de savoir quel est l'intérêt de présenter cette nouveauté de Visual Studio 2015 dans un blog dédié à Microsoft Dynamics CRM. Et bien c’est tout simplement parce que ce nouveau Template nous permettra d'appliquer l'une des bonnes pratiques importantes de la programmation dans les développements .Net que nous réalisons pour l'application CRM, notamment les plug-ins et les activités de workflow personnalisées.

En effet, cette bonne pratique de développement que vous connaissez surement tous, consiste à séparer les différentes couches de l'application comme la couche métier, la couche d'accès aux données etc… Nous pouvons ainsi optimiser le code de l’application, aussi bien en termes de lisibilité que concernant sa structure afin d'avoir, par exemple, une couche métier indépendante et réutilisable. Ainsi, nous gagnons en lisibilité, en fiabilité et en capacité de maintenance.

NB : dans cet article nous parlons des projets de plug-ins, à noter que le même principe est valable également pour les projets d'activités de workflow personnalisées.

Si nous souhaitons appliquer cette bonne pratique dans nos développements de plug-ins, nous pourrons découper notre code à minima à deux couches de code séparées :

·       Une couche pour gérer le contexte du plug-in tels que le message d'exécution, l'instanciation des services, la validation de l'étape de traitement, la validation de l'entité etc…, cette couche est implémentée dans le projet Plug-in lui-même

·       Une couche de service qui implémente toute la logique métier de l'application et qui ne dépend pas du contexte d'exécution

En pratique, comment pourrons-nous mettre en place cette architecture tout en prenant en compte les restrictions de Microsoft Dynamics CRM ?

Attention, n'oubliez pas que si vous séparez votre code en plusieurs projets, vous devriez référencer dans votre projet principal de plug-ins les .dll des autres projets. Il sera donc ensuite nécessaire de déployer ces .dll dans le GAC (cache d’assembly global) du serveur où les plug-ins doivent être exécutés. Ce qui complique notre installation dans le cas de CRM On-Premise et la rendre impossible dans le cas d'un CRM online, car vous ne pouvez pas accéder au GAC du serveur online. 

Comment faire alors ?

Le nouveau Template de Visual Studio 2015 "Shared Project" répond parfaitement à ce besoin. Les Shared Project permettent de partager du code source (classes, méthodes, etc…) avec d'autres projets qui les référencent, exactement comme les Bibliothèques de classes, mais sans DLL compilée distincte.

Donc, nous pouvons isoler notre code métier dans un projet partagé, puis le référencer dans notre projet de plug-ins, et tout cela sans créer de dépendance entre les bibliothèques des deux projets.

Voici la procédure à suivre pour créer un projet partagé et le référencer dans un projet de plug-ins.

Pour commencer, j'ai créé une solution Visual Studio vide, puis j'ai rajouté un projet Plug-ins et un projet Workflow de type Bibliothèque de classes :

Ensuite, pour créer un projet partagé : Clic droit sur la solution > Ajouter > Nouveau projet > puis sélection "Projet partagé :

Maintenant, vous pouvez ajouter votre code métier dans ce projet partagé. Créez par exemple la classe ContactService.cs:

Puis, ajoutez dans cette classe une fonction exemple, comme suit :

Ensuite, pour référencer votre projet partagé dans le projet plug-ins, dans la fenêtre Explorateur de solutions > Développer le projet plug-in > Clic droit sur Références > Ajouter une référence > onglet Projets partagés > cocher votre projet partagé > Cliquez sur Ok

L’explorateur de solution doit ressembler à cela :

Et voilà, vous pouvez maintenant utiliser la classe déclarée dans le projet partagé dans votre projet plug-ins :

Après compilation, le répertoire bin\Debug du projet plug-ins ne contiendra qu'une seule dll qui embarque le code du projet plug-in ainsi que le code du projet partagé.

J’espère que cet article peut vous être utile.

Merci beaucoup d'avoir visité mon blog et à très bientôt :)