Choosing Between Windows Forms and Web Forms

Choosing Between Windows Forms and ...

Switch on low bandwidth view

Collapse All

This page is specific to

Microsoft Visual Studio 2008/.NET Framework 3.5

Other versions are also available for the following:

Visual Studio Programmer's Guide for the .NET Framework

Choosing Between Windows Forms and Web Forms

When you begin developing applications with a user interface, you can use either Windows Forms or Web Forms. Both have full design-time support within the development environment, and can provide a rich user interface and advanced application functionality to solve business problems. Because of this feature parity, you might find it difficult to decide which technology is appropriate for a given application.

Certain application considerations might make the choice obvious. For example, if you are creating an e-commerce Web site that will be accessible to the public over the Internet, you would develop the application using Web Forms pages. If you are building a processing-intensive, highly responsive application that needs the full functionality of the client computer—such as an office productivity application—you would use Windows Forms. However, in other cases the choice might not be so clear.

The following sections discuss the features and characteristics of each technology to help you determine which is best suited to your application.

When to Use Windows Forms

You develop applications with Windows Forms when you want the client application to be responsible for much of the processing burden in an application. These client applications include Win32 desktop applications that were traditionally developed in previous versions of Visual Basic and Visual C++. Examples include drawing or graphics applications, data-entry systems, point-of-sale systems, and games.

These applications all rely on desktop computer power for processing and high-performance content display. Some Windows Forms applications might be entirely self-contained and perform all application processing on the user's computer. Games are often written this way. Other applications might be part of a larger system and use the desktop computer primarily for processing user input. For example, a point-of-sale system often requires a responsive, sophisticated user interface that is created on the desktop computer, but is linked to other components that perform back-end processing.

Because you build a Windows Forms Windows application around a Windows framework, the application has access to system resources on the client computer, including local files, the Windows registry, the printer, and so on. This level of access can be restricted to eliminate any security risks or potential problems that arise from unwanted access. Additionally, Windows Forms can use the .NET Framework GDI+ graphics classes to create a graphically rich interface, which is often a requirement for data-mining or game applications.

When to Use Web Forms

You use ASP.NET Web Forms to create applications that primarily have a browser user interface. Naturally, this includes applications intended to be available publicly through the World Wide Web, such as e-commerce applications. But you can use Web Forms to create more than just Web sites—many other applications lend themselves to a "thin front end" as well, such as Internet-based employee handbook or benefits applications. An important benefit of any Web Forms application is that it has no distribution costs. Users already have installed the only piece of the application that they need—the browser.

Web Forms applications are platform-independent—that is, they are "reach" applications. Users can interact with your application regardless of what type of browser they have and even what type of computer they are using. At the same time, you can optimize Web Forms applications to take advantage of features built into the most recent browsers, such as Microsoft Internet Explorer 6.0, to enhance performance and responsiveness.

Note:
In many cases, this optimization is built into the Web Forms components you use. These components can automatically detect browser levels and render pages accordingly.

Web Forms applications offer some features that are useful even in non-Web contexts. Because they rely on HTML, Web Forms applications are suitable for text-intensive applications of any sort, especially those in which text formatting is important. While browser-based applications usually have limited access to users' system resources, this limitation makes Web Forms applications helpful in situations where you want to prevent users' access to portions of your application.

Comparing Windows Forms and Web Forms

The following table provides a side-by-side comparison of different application criteria, and how Windows Forms and Web Forms technologies address these criteria.

Feature/Criterion	Windows Forms	Web Forms
Deployment	Windows Forms allows "no-touch" deployment with ClickOnce, where applications can be downloaded, installed, and run directly on the users' computers without any alteration of the registry. For more information about ClickOnce, see ClickOnce Deployment Overview.	Web Forms has no client deployment; the client requires only a browser. The server must be running the Microsoft .NET Framework. Updates to the application are made by updating code on the server.
Graphics	Windows Forms includes GDI+, which enables sophisticated graphics for games and other extremely rich graphical environments.	Interactive or dynamic graphics requires round trips to the server for updates when used on Web Forms. GDI+ can be used on the server to create custom graphics.
Responsiveness	Windows Forms can run entirely on the client computer; It can provide the quickest response speed for applications requiring a high degree of interactivity.	If you know that users will have Internet Explorer 5 or later, a Web Forms application can use the browser's dynamic HTML (DHTML) capabilities to create a rich, responsive user interface (UI). If users have other browsers, most processing (including UI-related tasks such as validation) requires a round trip to the Web server, which can affect responsiveness.
Form and text flow control	Windows Forms grid positioning gives you precise two-dimensional control (x and y coordinates) over the placement of controls. To display text on Windows Forms, you insert the text into controls (for example, the Label control, the TextBox control, or the RichTextBox control). Formatting is limited.	Web Forms is based on HTML-style flow layout and therefore supports all the features of Web page layout. It is particularly rich in text formatting support. Control layout can be managed adequately (with some limitations, such as no overlapping controls). If the users have DHTML-capable browsers, you can specify much more precise layout with two-dimensional (x- and y-coordinate) layout.
Platform	Windows Forms requires the .NET Framework running on the client computer.	Web Forms requires only a browser. DHTML-capable browsers can use extra features, but Web Forms can be designed to work with all browsers. The Web server must be running the .NET Framework.
Access to local resources (file system, Windows registry, and so on)	Applications, when permitted, can have complete access to local computer resources. If required, the application, with precision, can be restricted from using specific resources.	Browser security prevents the application from accessing resources on the local computer.
Programming model	Windows Forms is based on a client-side, Win32 message-pump mode, where instances of components are created, used, and discarded by the developer.	Web Forms relies on a largely asynchronous, disconnected model, where components are loosely coupled to the application front end. Typically, application components are invoked through HTTP. This model may not be suitable for applications requiring extreme throughput from the user end or for those with high-volume transactions. Similarly, Web Forms applications may not be suitable for database applications that require high levels of concurrency control (for example, pessimistic locking).
Security	Windows Forms uses permissions in its implementation of code access security to protect computer resources and sensitive information. This allows careful exposure of functionality, while retaining security. For instance, the Printing Permission, which at one level would allow printing to the default printer only, at another level would allow printing to any printer. Using ClickOnce, developers can easily configure which permissions their applications should and should not demand from the client. For more information, see ClickOnce Deployment and Security.	Authorization to gain access to the resources of a Web application is typically controlled on a per-URL basis by authenticating the credentials (for example, a name/password pair) of the requestor. Web Forms allows the developer to control the identity under which server application code is executed. Applications can execute code with the identity of the requesting entity, which is known as impersonation. Applications can also dynamically tailor content based on the requestor's identity or role. For example, a manager could receive access to a site, or a higher level of content than someone with lower permissions.

Concepts

ClickOnce Deployment Overview

Reference

Windows Forms Overview