‘La voie de SharePoint’

Group. Selon elle, « SharePoint présuppose une poignée de modèles de conception et vous devez, en quelque sorte, créer votre application autour de ces modèles.

Si vous souhaitez avoir votre propre modèle de conception, cela n’en vaut probablement pas la peine, que ce soit en termes de temps et d’effort. N’essayez pas d’intégrer de force d’autres modèles de conception, car ce sera au final extrêmement frustrant. » Andrew établit un parallèle avec les projets de programmation ASP.NET, pour lesquels les développeurs commencent généralement par construire une infrastructure afin de traiter les questions d’administration, de sécurité, d’accès aux données, etc. Selon lui, SharePoint se comporte pour l’essentiel comme l’infrastructure.

« L’avantage pour le développeur SharePoint est qu’il connaît déjà l’infrastructure et qu’il n’a pas besoin d’en apprendre une nouvelle », explique-t-il. Le problème est que l’infrastructure SharePoint est tellement vaste que les développeurs créent souvent du code personnalisé pour des fonctions qui existent déjà. Harbar exhorte les développeurs à prendre le temps de tout examiner avant de conclure à la nécessité d’un composant WebPart ou d’une application personnalisés.

« Sans aucun doute, l’erreur la plus courante consiste à ne pas avoir une connaissance approfondie de l’architecture du produit et donc de choisir la mauvaise approche pour répondre à des exigences métier spécifiques. SharePoint est une plate-forme tellement vaste qu’il est incroyablement facile de commencer à implémenter du code personnalisé pour une tâche que SharePoint est capable d’accomplir », écrit Harbar.

Toujours selon lui, les développeurs commettent souvent l’erreur de supposer que SharePoint est du « .NET et rien d’autre », alors qu’en fait les développeurs .NET doivent franchir un certain palier pour maîtriser les projets de développement SharePoint. Même au sein de la famille SharePoint, il y a des choix à effectuer. Selon Manes, nombre d’entreprises adoptent à l’heure actuelle le développement pour SharePoint Server, alors qu’elles pourraient obtenir des résultats similaires et bénéficier d’un environnement plus gérable en déployant la logique sur WSS (Windows SharePoint Services).

De son point de vue, les entreprises concluent souvent, à tort, que WSS n’a pas les fonctionnalités nécessaires pour gérer le workflow, la coordination, la planification et d’autres processus métier courants. « WSS comporte une multitude de fonctionnalités dont Microsoft ne parle pas au reste du monde », explique Manes.

« Je peux employer une portlet Java et en faire l’interface dans WSS, car cela passe par l’interface de services Web et non via l’interface .NET. » Pour conclure, le Microsoftien Andrews explique que les développeurs .NET doivent apprendre à désapprendre certaines de leurs anciennes certitudes lors du passage à SharePoint. « L’un des problèmes est le suivant : les gens pensent que leur expérience .NET va leur permettre de mener à bien leur projet SharePoint et cela tient au fait que les projets doivent être bouclés rapidement », déclare Andrews. « Il leur faut réellement apprendre de nouvelles compétences. »