I promised that I would explain a little bit about what “Application Model” means, and more specifically what it means for Avalon. Before we can even get too far there, it’s interesting to ask a simple question: what do we mean by “application” in the first place?
A lot of application platforms don’t do a great job of answering that question. Take these two big categories of app development platforms as examples:
- Desktop Applications: In the traditional desktop app world, there hasn’t ever been a very good model for what an application actually is. Take Win32, for example — here an application is roughly a set of windows in the same process. Because there isn’t an entity representing the app itself, the traditional practice is to pump messages (WM_EXIT) to the main window’s wndproc. State management and manipulation isn’t as hard as it is on the Web, but it is left up to the developer.
In the Windows world, perhaps the best we’ve done so far in this area is with Windows Forms, which provides an Application class that starts and stops the message loop and receives system messages.
- Web Applications: There are some parallel issues in the Web development world. Traditionally, a Web “app” is roughly a set of pages hosted on the same server (usually) that are part of some interactive user activity. Most of the “application-ness” comes from communication with the server, which is done through post-back (and the user experience of post-back is of course sub-optimal, especially for users with slow connections). State management is hard, especially when passing data between pages because of the lack of structured data.
Today we have server-side scripting languages that make “application-ness” for Web apps easier to grok. ASP.Net, for example, provides application-level services for state and session management. Additionally, there have been advances in ASP.Net that enable more and more things to happen on the client side and thus reduce post-back.
With Avalon, we’ve learned some lessons from both of these app paradigms. We’ve defined an application in terms of an object that represents application-ness (which is a godsend for those of us who can’t help thinking in object-oriented terms most of the time), and provided object model there that lets our developers manage common application-related activities. Thus we are able to leverage some of the lessons we’ve learned from other app platforms by:
- Providing a well-defined entity for system interaction (the Application class).
- Enabling you to customize that entity by hanging any state off of it that you want.
- Enabling you to listen to app-wide events at the Application level.
- Providing simple object model around window management.
- Handling resource management for you, allowing you to refer to your application’s embedded resources (pages, images, etc.) using relative URIs (a lot more on this topic later).