David REI

Comme vous le savez très certainement, Visual Studio 2010 apporte un modèle de projet spécifique pour SharePoint 2010, et bien que ce modèle de projet ne permette pas de réaliser plus de choses qu’avant, il simplifie beaucoup la lisibilité d’une solution WSP pour SharePoint.

Comme vous peut-être, il m’est arrivé de voir des exemples de projets, ou des preuves de concept mais aucune vraiment sur des projets importants d’entreprises avec un nombre conséquent de WebParts, de types de contenu, de receivers, … Et lorsque je réalise un projet SharePoint, j’aime bien m’assurer qu’il réussira à encaisser les changements, et/ou évolutions en terme de fonctionnalité, tout en gardant une certaine lisibilité pour le développeur.

Certains me diront, que l’on peut réaliser plusieurs WSP, et à juste titre mais je préfère cibler les choses plutôt que de multiplier les WSP sur la ferme.

Donc, le problème est finalement ; comment construire ma solution pour :

- Avoir une vision clair de mes développements

- S’assurer que tous les développeurs travaillent de la même façon

- Supporter le changement, les évolutions

- Contrôler les développements (Test unitaires, …)

Je vais prendre le cas de la solution suivante « DemoUpgrade.wsp », et vous exposer comment j’essaye de répondre à cette problématique avec le modèle de projet standard Visual Studio 2010.

- Tout d’abord je préfixe chaque "feature” par sa portée. Ainsi sur 50 features, il est plus facile de les identifier du premier coup d’œil. (Site_WebParts pour l’ensemble des WebParts par exemple).

- Tous les éléments sont organisés dans une arborescence sous forme de dossier, caractérisant son contenu. (WebParts, Lists, ..). On peut si besoin créer des sous rubriques pour organiser un peu mieux le répertoire s’il devient trop important.

- J’utilise les « _ » dans les séparateurs de feature, car lors de la génération, Visual Studio préfixe les features avec le nom de la solution + « _ », ce qui garantit une harmonie au niveau du nommage.

- Bien que les « Mapped Folder » permettent de mapper n’importe quel répertoire du 14, je vais très certainement perdre en lisibilité si je mappe tous les répertoires au niveau 1, donc j’ai choisis de garder mes habitudes 2007, en mappant directement le 14.

Attention aussi aux espaces de noms, lorsque Visual Studio vous propose les éléments en création ... !

Exemple avec « SAPViewerWebPart », l’espace de nom dans « SAPViewerWebPart.cs » est  «DemoUpgrade.WebParts.SAPViewerWebPart » … «DemoUpgrade.WebParts » est plus en phase avec les bonnes pratiques. Il faudra aussi modifier le .webpart pour qu’il soit en accord avec le changement précédent.