J'ai un POV que vous devez utiliser SharePoint pour le développement d'applications dans ces conditions.
1) L'application utilise des documents et ces documents ont besoin d'une sorte de fonctionnalité que SharePoint fonctionne extrêmement bien (recherche / indexation, synchronisation avec Outlook, etc.) si tout ce que vous voulez est un godet de document et une liste, puis ASP. NET ou ASP.NET MVC.
2) L'application doit utiliser des flux de travail ou des flux de travail personnalisés. Pas de flux de travail, alors à nouveau je regarderais vers ASP.NET ou ASP.NET MVC.
3) La société doit être disposée à consacrer au moins 1 développeur à temps plein à SharePoint. Pas 1/2 ou un 1/3 d'un développeur. Vous avez besoin d'engagement et de vous concentrer pour faire du développement SharePoint correctement. Vous devez boire le kool-aid. Si vous n'êtes pas disposé à se spécialiser dans SharePoint, mais que je ne suis que disposé à barboter, les solutions résultantes sont terribles (IMHO). Encore mieux si vous pouvez consacrer deux développeurs ou une équipe (pensez à la prise en charge / de maintenance / expertise / spécialisation).
Alors, que pensez-vous?
Remarque: Je pense que tous les magasins Microsoft doivent utiliser les fonctionnalités hors de la zone de SharePoint si leur société a choisi de pair avec Exchange dans le cadre de leur architecture de collaboration. Je ne suis pas anti-SharePoint.
Après avoir été assis dans un atelier SP, j'ai appris que le flux de travail SharePoint n'est applicable que sur une base de liste SharePoint. Par conséquent, si votre flux de travail n'utilise pas les éléments de liste SharePoint, vous devriez probablement regarder la Fondation .Net Workflow ou quelque chose de coutume. Considérez cela un remplacement de mon article n ° 2.
4 Réponses :
Je serais d'accord. SharePoint Actuellement (Moss 2007 / WSS 3.0) rend un processus très douloureux et lent. Le seul point que je ne voudrais pas être en désaccord avec la partie de flux de travail. À mon avis, le flux de travail de SharePoint est presque inutilisable et devrait être évité. Si vous allez faire des flux de travail, optez pour K2: Blackpearl ou Masstransit pour l'option libre open source.
Permettez-moi de clarifier. Je n'ai pas dit que le flux de travail SP était super. Je veux juste dire que si votre application n'a pas de flux de travail, pourquoi ne pas utiliser ASP.NET? Au fait ce qui est arrivé au transit de masse. Le projet est-il toujours très actif? +1 sur le lent et douloureux.
Oui, Masstransit est toujours actif. L'un des devins de tête sur ce que Chris Patterson est ici à Tulsa et la société qu'il travaille pour des utilisations dans leurs systèmes de production internes, donc même s'il n'a pas frappé v1.0, je pense que c'est assez stable ...
Espérons maintenant que MSFT résoudra beaucoup de Dev Points douloureux en 2010. J'ai une petite quantité d'espoir que faire de la mesure personnalisée en 2010 sera une proposition bien meilleure valeur.
Disons que vous disposiez d'un entrepôt de données qui collecte des données de nombreux points de la société. Espérons que vous avez quelques dimensions qui ont des entreprises d'affaires désignées comme "propriétaires de dimensions". Ce sont les personnes qui ont une participation dans l'organisation de données dans la dimension. Ils sont responsables de garder des choses comme des hiérarchies et des listes à jour, mais ces collections ne sont pas renseignées avec des données d'exploitation provenant de systèmes transactionnels, ce sont des termes et des groupes commerciaux et des descriptions que l'entreprise parle. C'est leur langage d'affaires naturel. Équipe des ventes de l'Est, petites entreprises, risque élevé, Promotion-AV Promotion 25, etc. Le point est votre entrepôt de données est construit à partir de 99% d'opérations / transactionnelles, mais ce sont les dispositions commerciales qui rendent toutes raisonnables pour vos utilisateurs et vous avez besoin d'un endroit pour le capturer.
Vous pouvez certainement faire une application Web. Vous pouvez utiliser un fichier Excel. Peu importe. Mais vous pouvez également utiliser une liste SharePoint. Où SharePoint est attrayant pour cela, c'est lorsque l'environnement existe déjà (et donc soutenu), lorsque vos besoins ne sont pas vastes, c'est-à-dire une intégrité référentielle non requise, vous n'avez pas les ressources nécessaires pour créer une nouvelle application Web, les utilisateurs professionnels sont déjà familiers et à l'aise avec SharePoint, vous en avez besoin hier, etc.
Je ne parle pas ici de l'écriture de code et de compiler des bibliothèques à installer sur SharePoint. J'essaie juste de présenter un "bon moment et un lieu" raisonnable pour qu'il soit utilisé.
BTW - Voici un Comment faire pression et tirant des données entre Listes SharePoint et SSIS .
je peux voir d'où tu viens. Mais dans 4 semaines, vous pouvez être assez proche de la duplication de la fonctionnalité de la liste de base dans SharePoint. Et puis vous avez un contrôle total sur l'application. Vous n'avez pas à travailler à travers une abstraction que vous n'avez aucun contrôle. J'espère que la SP fait quelque chose pour faciliter l'obtention de données d'une liste SP. S'il s'agit d'une partie centrale de la stratégie de Microsoft, les données devraient être aussi faciles que ODBC. +1 bon arguemnt et lien
Si vous utilisez un outil personnalisé tel que Metaman, à l'aide de SP en tant que surfaceur de données pour vos données d'entreprise, c'est beaucoup plus rapide, puis codez le vôtre. Mais vous perdez beaucoup de contrôle dans le modèle SP.
Perdre beaucoup de contrôle et $ en utilisant le BDC. Peut-être que si la BDC était libre ou partie standard de SP, il serait plus convaincant. Sur une tangente, il n'a pas de sens de charger des services Excel (ils ne sont pas très bons). Je fais vraiment comme la façon dont la recherche SharePoint fonctionne sur les données de BDC. +1 à Microsoft sur cela.
SharePoint devrait être utilisé comme fondement de la collaboration d'utilisateurs d'entreprises (qui étant de stocker, de trouver et de modifier les autres documents). En utilisant SharePoint, simplement pour les développements d'applications blesse et nécessite le point 3 effectué dans la question.
Pour le développement d'applications, je préfère utiliser SharePoint comme portail Web qui pointe des utilisateurs à l'application ou héberge son interface Web (via des contrôles utilisateur, des webparts et autres) (oh wait, je suis tout prêt dit SharePoint était un portail Web ).
Je suppose que cela signifie que nous sommes en quelque sorte d'accord. J'aime l'idée de l'utiliser hors de la boîte, mais pour le développement personnalisé, vous avez vraiment besoin d'un expert et d'une stratégie.
+1 sur le point d'accueil. Personnellement, je suis un grand fan du "modèle iframe" du développement SharePoint.
Même sans documents, vous pouvez toujours utiliser SharePoint comme une plate-forme pour un portail avec des webcarts personnalisés (certains d'entre eux sont peut-être basés sur des bibliothèques de documents de site). C'est une bonne plate-forme de portail et le portail de recherche de mon entreprise est basé sur SharePoint, et cela fonctionne plutôt bien. La bonne chose est que, avec le portail SharePoint basé sur les webparts, vous pouvez toujours prendre en charge les problèmes de permission et les problèmes de personnalisation de la présentation (faites glisser le WebPart sur une zone particulière, etc., que les utilisateurs font beaucoup, BTW) relativement facilement. En outre, WSRP Type WebParts fonctionne assez bien avec SharePoint.
Et vous avez raison, seulement si vous avez de bonnes Devs SharePoint Devs, cela vous facilite les choses et est une plate-forme décente, des documents ou pas de documents.
Je pense que partie de la partie de la raison pour laquelle les projets doivent être le bon ajustement pour SharePoint est le modèle de développement. Comme le déploiement de code sur le GAC et le rétablissement du pool d'applications. Douleur dans le cou sur un grand serveur Intranet SharePoint.