Chapter 8: Developing Desktop Applications
This chapter dives into the world of building enterprise desktop applications using the .NET Framework. Building desktop applications is quite different from building Web applications, but the implementation of both is nearly identical within the Visual Studio .NET environment. This chapter begins by answering the question "When should I build a desktop application?" The chapter then presents a classical application design pattern that is formulated into a structured application framework to enable you to quickly build a scalable enterprise application. Next , the chapter shows examples that implement data binding and extend application usability. Finally, the chapter presents an approach to application internalization as well as a method for packaging system resources into a shared assembly.
Building a Desktop Application Framework
As the previous chapter demonstrated, a structured application framework can go a long way in accelerating application development, reducing errors, and encouraging reuse. The same concepts hold true for building desktop applications. Before organizing a desktop application framework, you need to answer the question "When is an application implemented as a desktop application rather than a Web application?"
Deciding to Build a Desktop Application
During the dot-com boom, this was a simple question to answer; no matter what your requirements were, you built a Web application. In reality, the answer to this question is in the product requirements. The requirements may not necessarily specify a Web platform vs. a desktop platform, but they should outline specific needs such as global accessibility and access to local system resources. These are often the two most important factors in deciding which platform to target.
Global accessibility is a requirement that needs to be broken into two different parts : connectivity and target platform. If global connectivity is defined as building an application that can be accessed by any user connected to the Internet, then either application type will suffice. Desktop applications can be just as Internet accessible as native Web applications. The real question is target platform. If it is known that the target platform is certainly a Microsoft Windows platform, then a desktop application is ideal. If it is completely unknown or known to be a non- Windows platform, then a native Web application is ideal.
Access to local system resources is the other deciding factor. If the application requirements outline a need to access resources, such as local data files, Registry settings, or Component Object Model (COM) objects, then a desktop application will be required. Desktop applications will also have the advantage of rendering more quickly without the latency that comes with parsing a text-based Hypertext Markup Language (HTML) document. In fact, separate threads of execution might be spawned to perform lengthy business processing without presenting the appearance of "locking up" the user interface.
Understanding the Model-View-Controller Architecture
The roots of the modern three- tier application architecture stem from a classic architecture known as the Model-View-Controller (MVC) pattern . This classic design pattern has often been used by applications that require multiple views of the same data. The MVC pattern is based on a clean separation of application elements into three specific categories: models, views, and controllers. The model represents the application data. The views display all or a portion of the model. The controllers handle events that impact the model or views.
Because of this separation, multiple views and controllers can interact with the same underlying model. Furthermore, you can add new types of views and controllers that integrate into the model without requiring changes to the model.
Events cause the controller to change the model, the view, or both. When a controller changes the model's data, all dependent views automatically update. Similarly, when a controller changes a view, the view pulls data from the model to refresh itself. Figure 8-1 illustrates the relationship between the model, the views, and the controller.
Figure 8-1: The relationships between the model, views, and controller
Defining the Application Model
The model abstracts application data and has the capability to notify views when its values change. It contains only the data and functionality that serves a specific purpose. If you need to model two groups of unrelated data and functionality, then you should create two separate models.
In the context of a desktop application, the Data Access project can represent the model. The data binding capabilities of the views can represent the ability for the model to notify connected views of changes.
Implementing the Application Views
The views display all or part of the model to the user and change in response to changes in the model. There can be multiple views of a model, with each view rendering the model differently. By definition, a view can also aggregate any number of child views.
In the context of a desktop application, you might implement views as windows. The granularity can even vary from a simple textbox control to a complete Windows form. A Multiple Document Interface (MDI) application serves as a nice application model to implement an MVC pattern because multiple child forms can represent application data differently.
Implementing the Application Controller
The controller is the means by which the user interacts with the views and model. The controller is responsible for mapping user action to application response. The model, views, and controller must be tightly bound by references to each other.
In the context of a desktop application, the controller is simply a collection of event handlers. You can create any number of event handlers to respond to user commands that result in either changes displayed within the user interface or changes to the application data.
Applying Multiple Document Interfaces
Although the Single Document Interface (SDI) is the most common approach to application layout, enterprise applications often require more flexibility to display multiple types of data at the same time.
The purpose of MDI applications is to display multiple documents to the user at the same time. Each document is displayed in its own child window, leaving the parent frame with the ability to switch focus between documents. Each document is also capable of displaying a different representation of the same data. One form might display application data in a table format while another document displays the same data in a chart. This application model lends itself well to the MVC pattern, which is founded upon hosting different views of the same model.
Creating the MDI Parent
The most important element of the MDI application is the MDI parent form. The parent form contains and provides space for all child forms. The child forms, in turn , display the various views of the application data.
You create the parent form like any other Windows form in the Visual Studio .NET environment. The difference is that the parent form must have its IsMDIContainer property set to True. The parent form is also the startup form for the application, containing the Main method. It should, therefore, also include the application menu and status bar controls. Figure 8-2 shows the IssueTracker main form implemented as an MDI container form.
Figure 8-2: The IssueTracker main form and MDI container
Creating MDI Children
The next step in implementing an MDI application is to create one or more child forms. You create the child form like any other Windows form in the Visual Studio .NET environment. You can create any number of child forms to display application data differently and interact with the user.
The first form implements an All Issues view within the IssueTracker database, as shown in Figure 8-3. The simple form includes a single control (a list view control) that will display a variable number of rows in its details mode.
Figure 8-3: Displaying a summary collection within a list view control
The FormIssueDetails form, shown in Figure 8-4, implements the details view for a specific issue. This form includes a larger number of controls, including labels, textboxes, and combo boxes.
Figure 8-4: Displaying the details of an issue
After you create an MDI child form, you can display it within the parent form with only a few lines of code. Listing 8-1 demonstrates the initialization and display of an MDI child form within the FormMain_Load method of the parent container.
 |
private void FormMain_Load( object sender, System.EventArgs e ) { FormIssueSummary dlgSummary = new FormIssueSummary(); dlgSummary.MdiParent = this; dlgSummary.Show(); return; } | |
The code first instantiates a new instance of the FormIssueSummary class. After creating the form object, the code sets its MdiParent property to point to the main form and enables the Show method to be called to display the form. Figure 8-5 shows the result of the code as the child form is displayed within the parent.
Figure 8-5: The IssueTracker main form and MDI container
| Note | When an MDI parent form closes , each MDI child form generates a Closing event before the MDI parent is able to generate a Closing event. Clearing an MDI child's Closing event will not prevent the MDI parent's Closing event from being raised. |
Sharing Data Between MDI Children
Sharing data between forms is an eventual necessity with many different approaches. You should exchange data between forms as business objects managed by the Business Rules project.
You can pass business objects by value or by reference; choosing the right method will depend upon the application's needs. Passing business objects by value results is the most common and results in a separate local copy of the business object being created and used. Passing business objects by reference results in the exchange of a pointer to the original object. Changes made to the passed object result in changes to the original object.
EAN: 2147483647
Pages: 119