Once again, the paradigm under which we design applications is changing. Almost 3 years ago, I wrote the article "Win Forms vs. Web Forms" (http://www.windowsitpro.com/article/articleid/26991/26991.html) in which I discussed how Windows .NET Framework 1.0 had shifted the playing field and how it would enable "thick client" (aka "smart client" in our current terminology) applications to again dominate the development horizon. I still stand by my statement that smart client applications are taking over the development landscape. However, as they take over this landscape, there are changes occurring in how we'll approach designing smart client applications.
When I originally wrote "Win Forms vs. Web Forms," my expectation was that new applications would have a great deal in common with their COM-based predecessors, except for improvements in deployment technology and the use of XML Web Services. Thus, I foresaw that designers could use the .NET Framework to create a new version of an existing application that had been originally designed with Visual FoxPro or Visual Basic (VB) 6.0. If the .NET application was supposed to leverage a new UI, developers could go to sites such as the Microsoft .NET Framework Windows Forms Web site at http://www.windowsforms.com to download sample code that demonstrates how to leverage existing designs using the .NET technology.
For example, a year ago I was part of a team that was using the "Outlook Look and Feel" sample code from the Windows Forms Web site as the baseline for a client's application design. This sample code not only showed how to implement certain UI features but also provided an early outline of the application's design concepts, which we presented to end users for their feedback during the design stage. By leveraging an existing design model, we sped both the design process and the end user training associated with the application's release. You might think of this as "reuse at the design level"--it's a very effective way to design an application's interface.
When I was designing the client's application, another group of engineers at the company wanted to create reusable code for building applications (i.e., create a reusable application framework). In other words, instead of starting with a new Windows Form project in Microsoft Visual Studio for each new application, these engineers wanted to create a common UI code base that multiple applications could use.
The reusable application framework is separate from standard service- oriented DLLs that you can use to encapsulate data access or handle error logging, for example. These engineers wanted to create UI elements that provided common application capabilities and thus sped development. In theory, this is an excellent idea. After all, if you can reuse the same code across projects, you can reduce not only development time but also the amount of code you need to maintain. However, implementing a reusable application framework is much more difficult than reusing design ideas.
The company for which I work, InterKnowlogy, has worked with several clients to implement reusable application frameworks. Such projects tend to result in extremes--either complete success or limited success (corporate speak for failure). For example, one company hired us to work with its internal team of designers to architect, design, and implement a reusable application framework after the team's initial attempt failed. The now- complete framework lets the client successfully leverage a common code base and UI across several internal applications. Recently, another company asked us to help implement a reusable application framework. However, this framework had underlying design flaws that we were unable to address during implementation. Thus, the applications built on the framework have encountered several problems, resulting in more limited success.
Regardless of the level of success, both companies made a significant investment in a reusable application framework that might or might not be their path to the future. Because of the shifting technology landscape, this investment might come back to haunt them. On the one hand, I could and should say that the trend in application development is to create reusable application frameworks. After all, my employer works with clients to implement such frameworks. On the other hand, each of these clients has created a one-off framework--that is, their framework is unique to their organization. This uniqueness can be unfavorable because it means that developers moving from one company to another must learn a new framework. It also means that end users moving from one company to another must learn how to use a new application.
With the release of Visual Studio 2005, there's another option: Visual Studio Tools for the Microsoft Office System (VSTO). As I described in "Collaboration at the Office" (http://www.windowsitpro.com/article/articleid/42294/42294.html), this tool is an add-on to Visual Studio 2003. Under Visual Studio 2005, VSTO goes beyond letting you extend Microsoft Word and Excel applications. VSTO lets you build smart client applications that operate using Word, Excel, and other Microsoft Office products.
Currently, I'm working with a client that wants to use Office in just this manner. The custom VSTO application will communicate with centrally hosted XML Web Services and provide the general public with access to the company's application business logic. Given that this application is going to the general public, the company wants to leverage a much smaller installation footprint and a UI with which people are already familiar. This client doesn't want to create and maintain a complex application infrastructure. Instead, it's using Office as that infrastructure and letting Microsoft keep that infrastructure updated.
Of course, just noting that I'm using VSTO to build smart client applications isn't sufficient justification that this practice will become the wave of the future. However, consider the following: As I mentioned previously, a year ago I used the "Outlook Look and Feel" sample code for a client's application. However, the end users at the client site mainly worked with Excel in their daily activities. Thus, we spent a great deal of time adjusting the application features to fit the users' grid-based expectations while keeping the Outlook list-based UI. Had Visual Studio 2005's VSTO capabilities been clear over a year ago, I would have undoubtedly tried to convince the client to create this application as a VSTO application. Instead of all the development time spent creating and refining their generic application framework, the company could have focused on developing the business logic, thus reducing the project cost.
There are other advantages to using VSTO, including an easy-to-follow deployment model and users' familiarity with Office products. Thus, not only have smart client applications become a wave of the future but the ability to leverage Office to act as a reusable framework for custom applications takes this one step further. I currently know of only one book that will truly address the capabilities of VSTO: "Visual Studio Tools for Office: Using C# with Excel, Word, Outlook, and InfoPath" (http://www.awprofessional.com/title/0321334884).
Finally, I want to invite anyone who will be in the San Diego area around Labor Day to drop by the San Diego .NET Developer Group meeting on Tuesday September 6. The group invited me to speak about Visual Studio 2005 and SQL Server 2005. You can find more information about this free event at http://www.sddotnetdg.org.
