hile the Data Form Wizard creates a fully functional data-entry form, you are left with a result that embeds the data logic directly in the user interface. This article shows you how to separate the data logic from the user interface logic in a form created by the Data Form Wizard.
The Data Form Wizard accomplishes two goals: first, it provides an illustration of how the various ADO.NET objects work; and, secondly, it shows you how data-binding works in a Windows form. Note the choice of words: "accomplishes" not "accomplishes well!" In fact, the means by which the Data Form Wizard accomplishes what it does leaves the user with a moderately useful academic sample but nothing that could be used in a serious production application. Furthermore, if you are attempting to get a sense of how the ADO.NET objects work, it can be a rather daunting task when viewed through the lens of a data-aware form created by the Data Form Wizard. For example: Where is the line of demarcation between the user interface (UI) and the data? What belongs in the UI? What belongs in the middle/data tier? How does ADO.NET really work? This article attempts to answer these questions by investigating what the Data Form Wizard produces. Specifically, this article focuses on how the various ADO.NET objects work on their own as well as how they work together in their joint function of working with data. Where the Data Form Wizard combines and confuses, this article separates and clarifies.
A Review of What the Data Form Wizard Produces
The end result of the Data Form Wizard is a consolidated entity consisting of UI and Data Tier elements. The wizard embeds all of the data logic directly on the form. Specifically, all of the ADO.NET objects as well as the associated setup code are directly embedded. You can quickly conclude that what the Data Form Wizard produces does not fall within component-based/n-tier development methodologies. A moderate attempt at componentization is achieved by the wizard through a set of form-level methods. Still, the initialization steps for both the form and the various ADO objects are merged into a single block of code that would result in many printed pages of paper. It is important to note that the Authors Form, illustrated in Figure 1, is a relatively simple form with only a few UI elements.
|Figure 1: The initial version of the Authors Form produced by the Data Form Wizard.|
Taking just a few more moments to discuss the results from the Data Form Wizard, you'll find code that establishes a connection, a data adapter, a dataset and various command objects. These items, with perhaps the exception of the dataset object, are exclusively data related. Specifically, the UI does not need to directly deal with these items. In fact, the Data Form Wizard creates distinct form-level methods that act as an interface to the various operations that delete, update and insert data. If the Wizard created separate form methods, why not go the extra step of creating a separate class? The good news for you is that this article does just that!
Another observation is that the various command objects appear to require a lot of code to set up the various parameters. On one hand, you don't have to crank out the code manually since the wizard does the work. On the other hand, what the wizard leaves you with is something that cannot be reused. Are you trapped with having to crank out this code manually if you want reuse? Is there a generic way you can determine the structure of tables and command parameters? The answer is "yes" and this issue is addressed in this article, too!
Next, the Data Form Wizard has a Load button that grabs all of the data and marshals that data to a dataset for data-binding purposes in the form. In conjunction with this, the wizard provides a set of navigation buttons that enables the user to go to the first, last, next and previous data records. No scaleable client/server application of note works this way. Typically, when data is requested, the user provides information to lookup the data via a query. When the dataset is small, a pick list with two columns helps to navigate through data. At all times, the goal is to minimize the amount of data brought back to the client. This article also highlights techniques you can use to minimize the amount of data you bring back to the client.
Finally, by default the wizard produces client-side rendered Select, Update, Insert and Delete SQL statements for the various ADO.NET command objects. For reasons of performance and security, you want to make use of stored procedures whenever possible. As you might guess, this article also illustrates how to use stored procedures with ADO.NET.
Issues to Address in the Modified Design
The previous section paints a dim picture of the output produced by the Data Form Wizard. The news is not all that bad. In reviewing the code produced, you can conclude that the actual functions of ADO are somewhat obscured through a lot of code. However, you can get a sense of how the various ADO objects work. Still, it remains to be seen whether the way ADO is implemented in the wizard is optimal or not. If you worked with earlier versions of ADO, you had to marvel at its simplicity and, further, you had to scratch your head about how ADO.NET works. With this in mind, the broad issues to address are:
- Identify and segregate UI and data-related code
- Simplify the ADO.NET implementation
- Create a reusable middle-tier component to encapsulate data-related functions
- Create a UI to consume the services of the new data component
With the big issues identified, let's go about the task of improving upon what the Data Form Wizard left us!