Now that you have looked at some important functional components of SMO and their uses, it's time to look at the big picture and understand how the object model is structured from an architectural perspective. SMO consists of the following major components exposed to the user and shown in Figure 11-4.
Figure 11-4. SMO architectural diagram.
To obtain object properties, all SMO instance classes have to go through an internal component called Enumerator. Enumerator accepts generic metadata requests from its clients asking for a specific set of object properties. It turns these requests into valid T-SQL metadata queries and executes the queries against back-end Database Engine via a connection object. The Enumerator converts data coming back from the server into a usable format and returns it back to the caller. Although the major portion of Enumerator's functionality is dedicated to working with SQL Server Database Engine, it also has branches dealing with other types of data that need to be retrieved. For example, there are Enumerator branches that talk to Analysis Server, Notification Server, and WMI Provider.
To uniquely identify any SMO object, Enumerator uses the notion of Urn. It is a common property for all instance classes. Here is a sample Urn for the pubs.dbo.authors table:
Server/Database[@Name='pubs']/Table[@Name='authors' and @Schema='dbo']
Urn can also be used to instantiate an object directly through a class factory as follows:
Table table = serverInstance.GetSmoObject(tableUrn) as Table;