NPI: TaxonomySession

When working with the new taxonomy support in SharePoint 2010, the TaxonomySession class is high in the food-chain. The taxonomy functionality is provided through the new Service Application architecture and a central piece in accessing these is the SPServiceContext class.

When looking at the constructors of the TaxonomySession, it’s a complete mystery why one can only create one based on an SPSite and not SPServiceContext; especially when there is an internal constructor that takes a SPServiceContext.

For most use this may not be a problem, but think about deployment. During the deployment process you may want to populate a number of term sets because they will be used by site collections; you cannot create the term set unless you have a site that depends on the term set. Sure you could get around this by creating a dummy site collection, but why should you jump through these hoops?

Does anybody have a rational explanation why the internal constructor isn’t exposed? This is just one out of many examples on how SharePoint forces a certain way of programming on developers.

Advertisements

Non programmable interfaces

As you start digging into SharePoint, you will often find that what you really want access to isn’t available. SharePoint relies on a lot of internal classes and API’s. This wouldn’t be that bad if everybody had to play using the same rules, but there are two levels of SharePoint developers; those that work for Microsoft, and those that don’t.

If you look at the Microsoft.SharePoint.dll using reflector, a lot of SharePoint DLL’s are permitted to access these internal types.

Don’t be surprised if something is available through a standard page, but not through an API; aka NPI’s.