The Service Hierarchy

The most fundamental thing to be familiar with on this topic is the service hierarchy. You have already used it, whenever you make a call to GetService to obtain an instance of ISelectionService or IComponentChangeService. A service hierarchy is made up of several ServiceContainers. A ServiceContainer is used to store an instance of a class that provides a service against its type. So you request a instance by passing it a type, and it comes back with what you need.

When a ServiceContainer is created it is usually bound to a parent. This means that when a service is requested and it isn't in one container, it asks its parent, and then that asks its parent, and so on. ServiceContainers have no concept of children, only of parents. Using the example of the Visual Studio IDE, services are instantiated at several levels. At the document view level you have services such as ISelectionService and IComponentChangedService. These are obviously only relevant to one document (and only the design view, not the code view).

Look at the ITypeResolutionService interface though. Chances are you'll never use it, it's how the designers discover and instantiate types as they deserialize a document. Although the view-level ServiceContainer will get the request for it, it will be the ServiceContainer at the project level that will handle the request. Visual Studio is made up of a hierarchy of servicecontainers, from the toplevel ones that are used internally to manage menus and colours, to the document and view-level ones for editing documents. The image on the right shows a simplified look at part of this gierarchy.

It's very important when hosting designers to get the ServiceContainer hierarchy right - it can make things more logical and therefore more understandable. Always remember that the way everything at design time works together is by getting and using services from the host environment.