Designing the User Interface (and More Layers) in ASP.NET
Much of the success of any Web application depends on the quality of its user interface. As far as end-users are concerned, the user interface is the application: Users aren't interested in the details of the data model or the design of the data-access classes.
In an ASP.NET Web application, the user interface consists of a series of .aspx pages that are rendered to the browser using standard HTML. Designing the user interface is simply a matter of deciding which pages are required (and in what sequence) — and populating those pages with the appropriate controls.
Standard HTML has a surprisingly limited set of user-input controls:
- Text boxes
- Drop-down lists
- Check boxes
- Radio buttons
However, ASP.NET offers many controls that build on these basic controls. For example, you can use a GridView control to present data from a database in a tabular format.
All ASP.NET controls are eventually rendered to the browser, using standard HTML. As a result, even the most complicated ASP.NET controls are simply composites made of standard HTML controls and HTML formatting elements (such as tables).
Designing the user interface can quickly become the most complicated aspect of a Web application. Although user interface design has no hard-and-fast rules, here are a few guidelines you should keep in mind:
- Consider how frequently the user will use each page and how familiar he or she will be with the application. If the user works with the same page over and over again all day long, try to make the data entry as efficient as possible. However, if the user will use the page only once in a while, err on the side of making the page self-explanatory so the user doesn't have to struggle to figure out how to use the page.
- Remember that the user is in control of the application and users are pretty unpredictable. Users might give up in the middle of a data-entry sequence, or unexpectedly hit the browser's Back button.
- Some users like the mouse, others like the keyboard. Don't force your preference on the user: make sure your interface works well for mouse as well as keyboard users.
- Review prototypes of the user-interface design with actual users. Listen to their suggestions seriously. They probably have a better idea than you do of what the user interface should look like and how it should behave.
- Study Web sites that you consider to have good interfaces.
Designing the Business Rules Layer
Business rules are the portion of a program that implements the business policies dictated by the application. Here are some examples of business rules:
- Should a customer be granted a credit request?
- How much of a discount should be applied to a given order?
- How many copies of Form 10432/J need to be printed?
- How much shipping and handling should be tacked onto an invoice?
- When should an inventory item that is running low on stock be reordered?
- How much sick leave should an employee get before managers wonder whether he or she has been skiing rather than staying home sick?
- When should an account payable be paid to take advantage of discounts while maximizing float?
The key to designing the business-rules portion of an application is simply to identify the business rules that must be implemented and separate them as much as possible from other parts of the program. That way, if the rules change, only the code that implements the rules needs to be changed.
For example, you might create a class to handle discount policies. Then, you can call methods of this class whenever you need to calculate a customer's discount. If the discount policy changes, the discount class can be updated to reflect the new policy.
Ideally, each business rule should be implemented only once, in a single class that's used by each program that needs it. All too often, business policies are implemented over and over again in multiple programs — and if the policy changes, dozens of programs need to be updated. (That even hurts to think about, doesn't it?)
Designing the Data Access Layer
Much of the job of designing the Data Access Layer involves designing the database itself. Here are some pointers on designing the Data Access Layer:
- For starters, you must decide what database server to use (for example, SQL Server or Oracle).
- You'll need to design the tables that make up the database and determine which columns each table will require.
- You must also decide what basic techniques you'll use to access the data. For example, will you write custom data-access classes that access the database directly, or will you use ASP.NET's SqlDataSource control to access the database? And will you use stored procedures or code the SQL statements used to access the data directly in the application code?