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.

Comments

• Anonymous
  April 04, 2004
  Wow Eric, what you are suggesting (your "attractive characteristics") sounds great! When is .Net for Office...I'm sick of using VBA!
  
  Cheers, Thomas
  
• Anonymous
  April 04, 2004
  Great idea, this is very much needed. And if Microsoft were to undertake adding this kind of interface, one of the major requirements should be that it can be automated safely from outside the application to allow the server-side automation that Microsoft currently recommends against and doesn't support.
• Anonymous
  April 04, 2004
  The comment has been removed
• Anonymous
  April 07, 2004
  I definitely agree that we need to have object models for Office that can be used to create documents on the server. Turns out that VSTO 2.0 has some features in that area that I will blog about later that let you do some server side programming against Office documents.
• Anonymous
  April 09, 2004
  How I create a Word document Form-letter-like functionality in a web application