Is there any way to validate site ID without instantiating SPSite?

Question

I need a fast way to ensure that site ID is correct. Instantiating SPSite seems to be quite expensive, so may be there are other options to do this.

Answer 1

Assuming there isn't a method somewhere within the SharePoint object model that does this in some super efficient way (yeah, I couldn't find one either), I've done some testing that seems to suggest that the best thing to do is to access the relevant SPWebApplication object and enumerate that object's Sites property.

I created a quick test harness in the form of an application page with three buttons on it:

Once clicked, each button validates one or more site IDs using three different methods, each wrapped in an SPMonitoredScope instance:

1. Instantiating SPSite

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

2. Using current SPContext to access web application's Sites property (iterating with foreach)

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

3. Using current SPContext to access web application's Sites property (LINQ)

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

Obviously, the last two test cases are only useful if you can access a valid SPContext object. The question doesn't elaborate on where your code lives (timer job, event receiver, web part, web service, etc.) so I'm only assuming that you can access a valid SPContext. Another obvious note to call out: this very much depends on the topology of your farm, specifically the number of site collections involved.

Results

Example developer dashboard output:

The following numbers are averages based on 5 clicks per button:

1. Test with current site ID
   • Instantiating SPSite... (0.09 ms)
   • Using SPContext to access web application's Sites property (foreach)... (2.85 ms)
   • Using SPContext to access web application's Sites property (LINQ)... (2.28 ms)
2. Test with errorneous site ID
   • Instantiating SPSite... (2.42 ms) (interestingly much, much higher thanks to the exception)
   • Using SPContext to access web application's Sites property (foreach)... (2.33 ms)
   • Using SPContext to access web application's Sites property (LINQ)... (2.17 ms)
3. Test with 100 IDs (1 being the current site ID)
   • Instantiating SPSite... (189.08 ms)
   • Using SPContext to access web application's Sites property (foreach)... (2.14 ms)
   • Using SPContext to access web application's Sites property (LINQ)... (2.07 ms)

All that being said, I think it really depends on the nature of your comparison: how many IDs you're dealing with, how many site collections you're dealing with, etc. The win with the SPContext object is that it's already in memory, regardless of whether you're using it or not. If you're running through a collection of candidate site IDs within the context of a particular web application, my $0.02 is: grab the relevant SPWebApplication object and use a concise LINQ query to vet each ID:

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

Disclaimer: These tests were performed on a development farm with three web applications and only three site collections (one per web application). Windows Server 2008 R2, SharePoint Server 2010 (August 2011 CU) YMMV