Windows Forms

Windows forms are used when an application is going to take a huge amount of processing on the client side. Due to this, the Windows form-based application relies on the client computer's performance more than a Web-based application does. Later in this book, we will show you how to apply this "read-flow" rule when we create our example application in Chapter 9.

Regardless of whether you choose a Web-based application or a Windows-based application, the way you code behind the graphical controls is the same. The code behind the controls on the Web page (if it is a Web-based application you develop) is called a controller function. The controller function calls the Facade object to implement the desired action and retrieve the required data. Behind a user event you place a call to the controller function that in turn is calling your Facade class, as illustrated in Figure 5-19.

So what should you do and what shouldn't you do in the user interface? You should not invoke, vote, or participate in any transactions—the transactions should be handled from the business layer and further down in the architecture. When you are working with user input, you should validate the user input so you know the data is valid. But a good rule of thumb is to validate and detect errors as early as possible in the data flow to avoid round-trips to the server.

When you render data, your user interface will retrieve the data from the Facade objects and perform final formatting of values (such as formatting dates to the local formatting standard at the client). You also perform any other localization work on the retrieved data.

The user interface in a Windows application can be of different types. A standard Windows application has full support for all kinds of user interaction that gives your users a rich experience. The drawback with this type of application is that you are tied to using the Microsoft platform because Windows is the only operating system, so far, that has the complete .NET Framework implemented. One other drawback is that the application needs to be deployed. Another type of Windows application actually embeds HTML to allow for more flexibility, as the HTML can be fetched from external resources or even a database in a connected scenario. The drawback with this approach is that you need to protect yourself from malicious script being implemented in the HTML. You also need to include some additional coding to load the HTML and display it, and hook up the events from the application.

Another solution might be to develop the application as a plug-in to a host application such as Microsoft Word or Excel. This is one of the approaches taken for the publishing tool found in the Microsoft Content Management Server we will talk about later in the section "Content Management." The benefit from this is the user can use an application he or she is already familiar with, and thereby productivity can be high from start.

No matter which one of the mentioned Windows application types you decide to use, the need for a common approach to access your facades and the enterprise architecture is the same.

When developing Windows-based applications, you can rely a lot on data-bounded controls. This means that a control, for instance a list box, can bind to data that will be automatically updated when changes are made to it. This removes the need to write complex data synchronization code.

Always implement error handlers in the code as we mentioned previously in the section "Error Raising and Handling." You should also take care of errors and present them to the user in a friendly manner; a friendly manner does not mean presenting a stack dump to the user and saying "Oops something went wrong— please reboot your computer and have a fresh cup of coffee while you are waiting."

Web Forms

Our example application in Chapter 9 will have a Web-based user interface created in ASP.NET. When you develop a Web-based user interface, you may want to create a custom error page and a global exception handler in the global.asax file for your application. By doing this, you will catch all exceptions that are not handled by the application and thereby prevent the user from seeing a stack dump or something even worse.

ASP.NET has many great controls for validate user inputs, so it behooves you to take advantage of them. When you work with user input, you should validate the user input so you know the data is valid. (You may want to validate the data in the facade layer too since the client may not be able to validate the data input—this is true for a Web application in which client script has been disabled by the user.) A good rule to follow is to validate and detect errors as early as possible in the data flow to avoid round-trips to the server.

If you create your own Web controls, you should use the "abstraction" from OOP—only show the properties and methods that used. This improves the maintainability since the developer does not need to see unused properties and methods.

States can be handled in different ways. You can employ hidden fields in the page, using the view state functionality (which is quite similar to using hidden fields), or you can employ a separate state server that controls your states. The hidden field solution is not used so much nowadays; instead it is more common to use the view state functionality found in ASP.NET.

Note

Remember to turn off the view state if no state is needed between calls from the page. The view state generates a lot of text in the page that needs to be transferred between the client and the server in each call.

Implement your controller functions as separate functions instead of putting them directly in the event from where they are started. Doing so enables you to use the same controller function from different places in the page.