Microsoft Invents New IJS (It Just Sucks!) Technology

Navigation

Microsoft Invents New IJS (It Just Sucks!) Technology

Visual C++ has this cool technology called It Just Works, or IJW for short, which allows seamless interoperation between managed and unmanaged code. Now, with the introduction of Visual Studio Tools for Office 2005 Microsoft has obviously invented a new technology which I shall refer to as IJS - It Just Sucks!!

Before I get accused of being contraversial, let me qualify that statement. We've recently undertaken a project for a small business client who wanted a custom database app developing with a nice UI on the front end. For reasons best known to himsel the client has a booking form which he had implemented in Excel, though he only ever printed out blank copies and filled them in manually. With the introduction of the system we were developing he was keen to preserve his original booking form so we though we'd try using Visual Studio Tools for Office (VSTO) to hook his booking form up to the data we would be storing in the database. VSTO includes databinding facilites similar to Windows Forms/ASP .NET, so we thought they'd be ideal for achieving this. And in a way we were right. The data binding features of VSTO did allow us to present information from the database using the original Excel 'form' but the performance was dreadful. The form has up to 30 items of data it needs to be populated with and when it loaded it would take over 45 seconds to fully bind each item and display the form. In fact the performance was so poor you could actually watch the databinding setting the value of each individual cell. Being something of a VSTO virgin I thought I must have done something really numb to cause the dreadful performance, but the more I looked into it and read up on VSTO, the more I became convinced that I was using VSTO as intended and the perfomance just sucks. A bit of Googling started turining up posts like this on the VSTO Forum which showed that others have noted similar issues.

To put this into perspective, let me quote a few figures. The data binding we implemented in VSTO bound cells in the Excel document to data items retrieved from the database using a data access layer that we implemented using typed DataSets with a few custom classes to handle specific business illogic. As always, we built a test harness to exercise the data access layer and profiling this proved that the data access layer could load all the required data from the database in a matter of a few milliseconds. When we used the databound Excel spreadsheet to perform exactly the same operation it took over 45 seconds to display the spreadsheet properly. Given that the data access layer performed satisfactorily we had to conclude that the data binding was causing the poor performance and posts like the one referred to above bear this out. There was no way our client was going to wait 45 seconds for each booking record to be displayed so in the end we had to abandon VSTO and build him a WinForms UI instead. We're still using databinding against the same data access layer with the WinForms implementation and it now takes less than a second to load the record from the data access layer, perform the data binding and display the data in the UI.

In short, the data binding performance of VSTO just sucks! Our brief experience of developing with VSTO left us feeling like it was an unfinished piece of technology and definitely a work in progress. For example, Excel allows you to create NamedRange objects that correspond to a particular set of cells in the spreadsheet. The object model exposes events on the NamedRange class. Some of these pass in event args that refer to the range of cells related to the event, but not as NamedRange instance, but as an instance of the Range type from the underlying Office COM classes. VSTO seems to provide no way to translate a Range into a NamedRange or compare instancs of these two types. This makes it impossible to write generic event handlers which can deal with the same event from different cell ranges and respond to them accordingly. We ended up writing no end of virtually identical, repetitive event handling code to deal with events on the NamedRanges we were using. If we had been able to cast a Range to a NamedRange, or compare the two to see if they referred to the same group of cells, we could have replaced most of this with an if statements and 3 extra lines of code.

I'm sure there are probably some really cools bits of VSTO that I haven't explored yet which work really well, but based on experience so far I have to say It Just Sucks, and I for one intend to stay well clear of it until the technology is a bit more advanced.