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 ?
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 :)
Bonjour Youssef,
RépondreSupprimerLes objets générés sont-ils bien debuggables, contrairement aux éléments produits par ILMerge ?
Bonjour,
RépondreSupprimerEffectivement, un des avantages de cette solution est d'avoir la possibilité de debugger le code des deux projets plug-in et "Shared project", parce que nous déployons sur le serveur CRM toutes les dll et pdb générées apr VS à savoir 1 dll et 1 pdb, par contre dans le cas de ILMerge nous déployions que la dll fusionnée sachant que VS à générer plusieurs.