WSS 3.0 en tant que plate-forme d'application

Question

Ceci est une question d'architecture.

Nous sommes en train de construire un site de gestion de documents avec un flux de travail de base qui doit être externe. L'application externe doit être marquée et doit pouvoir charger et télécharger des documents et supporter le versioning. Nous avons Nous avons décidé d'utiliser WSS 3.0 comme outil de collaboration car il a toutes les fonctionnalités dont nous avons besoin. Nous prévoyons de soutenir plusieurs clients avec une personnalisation de la marque pour chaque client. Ma question est devrait devrions-nous exposer WSS au client pour faire face externe ou construire une application ASP.NET standard en utilisant WSS dans le niveau d'application et laisser l'application ASP.NET interagir avec WSS en utilisant le service Web/API WSS.Ceci Il est facile de personnaliser l'application ASP.NET sans avoir à apporter de modifications au WSS. Les utilisateurs internes n'ont pas besoin d'une image de marque et peuvent donc accéder au site WSS interne pour effectuer des activités de flux de travail. Construire des fonctionnalités et se familiariser avec la marque a été un défi depuis que j'ai commencé le développement de WSS.

S'il vous plaît laissez-moi savoir votre opinion.

Answer 1

Si vous ne connaissez pas beaucoup de choses sur SharePoint, il sera difficile de créer et d'exposer une interface utilisateur. Pouvez-vous le faire? Absolument. Devriez-vous le faire? Cela dépend de vos besoins et de votre niveau d'expertise avec SharePoint. À mon avis, le chemin le plus facile serait de créer une application ASP.NET et d'avoir cette interface avec SharePoint, mais je passe 90% de ma journée à travailler avec ASP.NET et ne fais que du développement SharePoint environ une fois par an. Dans mon expérience, si vous devez demander si vous devez construire un nouveau produit, etc. avec un outil, la réponse est généralement connue. Si je ne peux pas y répondre moi-même avec peut-être un coup d'oeil sur l'outil, j'essaie de ne pas l'utiliser sur un projet majeur, car cela signifie que je ne le connais pas assez pour me sortir de l'impasse se pose.

Answer 2

SharePoint est grand. Vraiment gros. Par conséquent, si vous envisagez de développer une couche intermédiaire maison entre vos clients et SharePoint, soyez prêt à faire beaucoup de travail à moins que vous ne prévoyiez d'exposer une petite partie de l'interface SharePoint.

Je recommande d'exposer WSS et de créer votre application au sein de l'infrastructure WSS au lieu d'être adjacente à celle-ci en créant des composants WebPart, des pages et des listes répondant aux exigences requises uniquement par SharePoint. Cela devrait réduire votre charge de travail à quelque chose de gérable. Jetez un oeil à des outils tels que VSeWSS ou WSPBuilder pour faciliter votre développement WSS 3.0 (si vous utilisez Visual Studio), et profitez de SharePoint Designer où cela est approprié.

Answer 3

Si vous faites une couche personnalisée sur WSS ci-dessous, vous écrivez essentiellement du code qui est déjà fourni avec la plate-forme, en particulier avec SharePoint. Je suppose que le prix est un facteur dans votre prise de décision ou que vous n'utiliseriez pas WSS seul. Dans ce cas, il peut être tentant de tirer parti de WSS en tant que couche de code, mais je m'attendrais à ce qu'il soit extrêmement difficile de faire en sorte que ce travail se déroule sans heurt. En fonction de votre modèle d'entreprise, je regarderais ce que les solutions SharePoint hébergées peuvent faire, en particulier si vous pouvez héberger une définition de site SharePoint personnalisée sur leur plate-forme.

Cela prendrait un IP ou un besoin financier très fort pour me faire envisager d'enrouler asp.net au-dessus de WSS.

J'ai travaillé avec une solution qui fait cela et qui fonctionne pour notre site externe, mais c'est une maintenance 'mare.