Existe-t-il un moyen de valider l'ID du site sans instancier SPSite ?

Question

J'ai besoin d'un moyen rapide de m'assurer que l'ID du site est correct.L'instanciation de SPSite semble être assez coûteuse, il existe donc peut-être d'autres options pour le faire.

Answer 1

En supposant qu'il n'existe pas de méthode quelque part dans le modèle objet SharePoint qui fasse cela de manière très efficace (oui, je n'en ai pas trouvé non plus), j'ai effectué des tests qui semblent suggérer que la meilleure chose à faire est pour accéder à l’objet SPWebApplication pertinent et énumérer la propriété Sites de cet objet.

J'ai créé un harnais de test rapide sous la forme d'une page d'application avec trois boutons dessus :

Une fois cliqué, chaque bouton valide un ou plusieurs ID de site à l'aide de trois méthodes différentes, chacune enveloppée dans une instance SPMonitoredScope :

1. Instanciation de SPSite

   try
   {
      using (SPSite site = new SPSite(siteId)) {}
   }
   catch {}
   

2. Utilisation du SPContext actuel pour accéder à la propriété Sites de l'application Web (en itérant avec foreach)

   var sites = SPContext.Current.Site.WebApplication.Sites;
   foreach (SPSite site in sites)
   {
      if (site.ID == siteId)
      {
         // site found
         break;
      }
   }
   

3. Utilisation du SPContext actuel pour accéder à la propriété Sites de l'application Web (LINQ)

   var site = SPContext.Current.Site.WebApplication.Sites.FirstOrDefault(x => x.ID == siteId);
   if (site != null)
   {
      // site found
   }
   

Évidemment, les deux derniers cas de test ne sont utiles que si vous pouvez accéder à un fichier valide. SPContext objet.La question ne précise pas où se trouve votre code (tâche de minuterie, récepteur d'événements, composant WebPart, service Web, etc.), donc je suppose seulement que vous peut accéder à un valide SPContext.Autre remarque évidente à signaler :cela dépend beaucoup de la topologie de votre ferme, en particulier du nombre de collections de sites impliquées.

Résultats

Exemple de résultat du tableau de bord du développeur :

Les chiffres suivants sont des moyennes basées sur 5 clics par bouton :

1. Tester avec l'ID de site actuel
   • Instanciation de SPSite...(0,09 ms)
   • Utilisation de SPContext pour accéder à la propriété Sites de l'application Web (foreach)...(2,85 ms)
   • Utilisation de SPContext pour accéder à la propriété Sites de l'application Web (LINQ)...(2,28 ms)
2. Test avec un identifiant de site erroné
   • Instanciation de SPSite...(2,42 ms) (ce qui est intéressant, beaucoup plus élevé grâce à l'exception)
   • Utilisation de SPContext pour accéder à la propriété Sites de l'application Web (foreach)...(2,33 ms)
   • Utilisation de SPContext pour accéder à la propriété Sites de l'application Web (LINQ)...(2,17 ms)
3. Test avec 100 identifiants (1 étant l'identifiant du site actuel)
   • Instanciation de SPSite...(189,08 ms)
   • Utilisation de SPContext pour accéder à la propriété Sites de l'application Web (foreach)...(2,14 ms)
   • Utilisation de SPContext pour accéder à la propriété Sites de l'application Web (LINQ)...(2,07 ms)

Cela étant dit, je pense que cela dépend vraiment de la nature de votre comparaison :combien d'identifiants vous gérez, combien de collections de sites vous gérez, etc.L'avantage de l'objet SPContext est qu'il est déjà en mémoire, que vous l'utilisiez ou non.Si vous parcourez une collection d'ID de sites candidats dans le contexte d'un particulier application Web, mon 0,02 $ est : récupérez l'objet SPWebApplication approprié et utilisez une requête LINQ concise pour vérifier chaque ID:

var site = SPContext.Current.Site.WebApplication.Sites.FirstOrDefault(x => siteIds.Contains(x.ID));
if (site != null)
{
   // site found
}

Clause de non-responsabilité:Ces tests ont été effectués sur une ferme de développement avec trois applications Web et seulement trois collections de sites (une par application Web).Windows Server 2008 R2, SharePoint Server 2010 (CU d'août 2011) YMMV