In "Basics of the .NET Framework: ADO.NET," I discussed how the .NET Framework makes database information available to its applications. But what does the UI for .NET applications look like? The UI is as important to the .NET Framework as is access to databases and operates at roughly the same place in the architecture. This time, we'll look at Windows forms, also known as Web forms, which are a fairly language-agnostic way of providing a front end to the Web services and ADO.NET used in .NET applications. They're Microsoft's answer to a common applications dilemma: namely, how to make applications easy to maintain and use. Of the three current models for applications, all fall short in one way or another.
Applications running on user workstations are available whether the person using them has a network connection or not, and they benefit from having an entire computer's resources dedicated to them. But installing and maintaining those applications requires administrators to touch user workstations, either manually or programmatically, through instruments such as group policies. Also, locally installed applications can hurt a workstation if they're poorly written because they can overwrite files that other locally installed applications need.
Applications running on a terminal server are easier to install and update because updating one server takes care of all the clients using it. However, not all applications are terminal server-friendly, and you can't use those that are without a network connection. (The need for a live network connection was one of the stumbling blocks for the application service provision model--few people wanted to pay to use applications they couldn't get to if their broadband connection was down.) Browser-based applications don't affect the client workstation and, like applications running on a terminal server, are accessible from any computer running a browser, not just from the computer on which they're installed. However, they also depend on a network connection and might not be as powerful as regular Win32 applications.
Web-based applications have a downside, too. Web-based applications are also usually kept separate from locally installed resources such as disk drives (mostly because it's hard to limit the applications' access after the application has the access) and workstation-based applications.
Windows forms are supposed to simplify .NET application development and management while making the applications as useful as possible. First, Visual Studio .NET, the development tool for Windows forms, works with any language supported in the Common Language Runtime (CLR), so you're not limited to using Visual Basic. Windows forms use controls (such as buttons) for the UI, and events (such as clicking a button) to initiate action. They support existing controls but also add some controls, such as Link Label (which adds a hyperlink to an application), Tray Icon (which puts an application in the system tray), and Print Preview (which shows print job output before printing). You can create a standard form and then make that form inheritable for all other applications to easily give all applications in a suite a similar look and feel.
Second, applications using Windows forms are simple to deploy. Rather than sending users a package to install, or setting up group policies, you can make applications self-deploying by providing a link to a URL that contains the application's executable. Connecting to this link downloads the executable, which then sets up the application from the network and then uninstalls it when the user is done with the application. Alternatively, according to this model you can copy the application to the user desktop and let it run locally.
Few applications use Windows forms now. However, the idea is to create language-agnostic applications that can run either from a central server or from the local computer, depending on what works best in a given situation.