Office Object Model Thoughts

Currently, one of the greatest obstacles faced by Office developers is the difficulty of using the Office object model. Just calling the object model the “Office object model” is incorrect—it is really several separate object models, one for Excel, one for Word, one for PowerPoint, etc. Each object model has different naming schemes, different ways of doing similar things, and different approaches to the world that are highly influenced by the implementation details of each application.

What are some of the key problems that make Office development difficult?

1. Office is actually a set of several independent applications, each with an object model that behaves differently. It is difficult to write a solution that takes advantage of the capabilities of multiple applications because each application’s object model must be learned.

2. Structured data created in one application is difficult to transfer to another application programmatically.

3. Object models are very granular and force the developer to solve problems at a very low level that is very specific to the implementation of a particular Office application. Office solutions can be slow because of the number of calls required to do simple tasks.

4. It is difficult to bring in outside data from .NET data types, data sets, XML, and transform it to Office objects and vice versa.

Much of what the .NET Framework was about was taking disparate Win32 API’s and “upleveling” them to present a higher level set of classes that developers could use to get things done easier. Using the .NET Framework, developers are able to work at a higher level and write much less code. At some point, I really believe that Microsoft needs to undertake the same task to provide a .NET Framework for Office that makes it so developers have to write less code and can work at a higher abstraction level.

However, until that .NET Framework for Office comes along, we can solve key Office development problems by making schema, data, XML, and data binding integral parts of Office programming. In Office 2003, Word and Excel added support for mapping XML schemas into a document to provide structure to the data in documents. By using this mapping as an intermediary step between the developer’s code and the actual calls to the Office client application object model, we can provide a programming model for Office that has several attractive characteristics:

1. The fact that Office is several independent applications can be obscured.

2. Developer code can be retooled to focus on higher level abstractions rather than details of a particular underlying office application’s object model.

3. Document content can be moved (as XML data) from one format to another. For example, a list of orders can move from easily from a database to an Excel spreadsheet to a word document through schema mappings to the spreadsheet and document.

4. When developer code focuses on programming against the data, we can make possible server side “content creation” scenarios where launching the Office application is not desirable.

More in my next post where I will talk about data/view/client OM separation and what it buys you from a programming model standpoint.