When first given a new SDK, what I do is immediately try to figure out the object model. This is how I try to understand what the SDK developer’s intent was and how he thinks I will or should use the new tools provided. Since documentation on the object model for the Live Framework toolkits is still in development today, I’d like to take a quick look of some pieces of the object model from a consumer’s perspective.
Here is the Resource Model from the SDK (http://msdn.microsoft.com/en-us/library/dd137022.aspx)
Everything in this hierarchy is either derived LiveItem or is a collection of those items. The LiveItem provides all the top level functionality needed to navigate the resource model and identify which nodes a developer is trying to find or modify. If you look at the methods provided by the LiveItem base class, they fit that model. For instance, there are methods to Load the data into the local object from the Live Framework, update it, and a Resource property to get to the actual data itself. The classes derived from LiveItem (e.g. MeshObject, Profile or DataFeed) provide additional members that are specific to their place in the resource hierarchy. For instance, the MeshObject contains a collection of the DataFeeds and the device Mappings.
Each LiveItem derived class is actually derived from LiveItem<TResouce> as seen in the following diagram.
The TResource property is a generic type that is defined by the derived type. The generic type provided to LiveItem as TResouce also must be derived from Resource. This is where the tight coupling between the LiveItems and the Resource items is created. For each LiveItem derived class, there is a corresponding Resource derived class.
So the definition of the MeshObject looks like this in C#
public class MeshObject : LiveItem<MeshObjectResource>
The Resource derived classes provide the actual data found at each node in the resource model, and is retrieved by accessing the Resource property of the LiveItem in question. For example, in order to inspect a DataFeeds properties such as Title or Type, you need to first navigate to the DataFeed in question through the resource model (e.g. Mesh->MeshObjects->DataFeeds) and then access the Resource property of the resulting DataFeed object. This property will be of type DataFeedResource and will have all the instance data for that data feed as well as any user defined data that was stored there.
So, to sum up, the resource model for the Live Framework Toolkit is primarily made up of two object types: LiveItem and Resource. Both these types are used as base classes for all the various node types within the resource model. And each one is paired with a corresponding derived type of the other. The LiveItem objects are used for resource model navigation and hierarchy updates. The Resource classes are used to store the data within the resource model nodes.
Krzysztof Cwalina, of the .NET Framework team at Microsoft and author of "Framework Design Guidelines," has provided a nice API analysis tool - <a href="http://code.msdn.microsoft.com/fds">Framework Design Studio</a>. This gives an easy way to look at the Live Framework APIs that is much faster and more complete than the online documentation.