Design of ASP. NET planning stage

Before directly entering the project encoding section, you need to spend a little time to actually outline the application. Program This is very important. In our example solution, we need to implement three logical components of the solution: database,. NET data access component, and ASP. NET user interface. Now, we first outline each component and discuss the most important aspect in the process, that is, interaction between document components.

Directory:

Database
Data Access Component
Message component
Other Data Access Components
Web user interface
Topic input screen
Summary and put into action

Database

For the dotnetkb application, we need to store the data in three tables: topic, question, and answer (SEE ).

Figure 3: topic, question, and answer table

We need to use stored procedures so that the middle layer components can also securely access data. Here, we only pointed out that the database documents that list the table name, all column details, default indexes, and Stored Procedure lists should be included in a complete database design document. That is, the document should have the detailed information required to successfully implement the system data storage.

Note: If you pay attention, you may notice that we did not mention storing expert data in the database. To make the project more interesting (and give us a chance to use direct XML data storage), we store expert information in an XML data file.

Data Access Component

The data access component design document depicts all the details of interaction with the data storage system and with the user interface. In some systems, the data access component is actually multiple assemblies that process various problems. For example, a series of business rules may appear on the user interface completely independent from data storage and retrieval. In this case, it may be wise to separate the business components from the Data Access Components.

In our example, two independent components are actually implemented: the message component and the dataaccess component. If you plan to support XML-based data transmission services (such as soap Web Service), this message-oriented implementation solution will be particularly effective.

Message component

The message component defines a series of classes used to transfer data between layers. These messages can exist as binary or XML text data. The value of the message layer is to protect the rest of the system from the details of the data storage implementation solution, such as SQL Server and XML files. In addition, by implementing the message layer rather than the more complex "intelligent object" library, our solution can more easily support remote call services that cannot send data and class-Level Logic at the same time, for example, XML-soap.

The following is a message class example, in which topic messages and their collections are implemented:

Public class topic private _ id as integer private _ title as string private _ description as string public property ID () as integer get return _ ID end get set (byval value as integer) _ id = value end set end property public property title () as string get return _ title end get set (byval value as string) _ Title = value end set end property public property description () as string get return _ description end get set (byval value as string) _ description = value end set end propertyend classpublic class topics inherits system. collections. collectionbase default public property item (byval index as integer) as topic get return ctype (List (INDEX), topic) end get set (byval value as topic) List (INDEX) = value end set end property public function add (byval s as topic) as integer return list. add (s) end function public sub remove (byval index as integer) list. remove (INDEX) end subend class

Note: If you have tried message-oriented design, you will understand that we want to serialize these message classes so that they can be easily sent back and forth between application layers. Fortunately, the. NET runtime knows how to perform this operation without having to do too much work. However, when we learn how to create a messageArticleWe will discuss in detail how to serialize classes during. Net runtime, and how to perform operationsCodeProcess optimization.

The details of this method will be described in the article when the message component and data access component are implemented later. The design document contains a list of all information, its attributes, and data types. Now, we just want to consider how to use this message method to encapsulate data transmission between layers, and how to create a common data service that works with local and remote solutions.

Other Data Access Components

After defining the concept of a message class, the data access component can focus on the details of direct conversations with the data storage system and return information in the correct message format. In our example, this involves ing requests from the user interface to the SQL Server Stored Procedure, and creating messages (or message sets) that can be returned to the user interface for display ).

For example, the following is a sample code of a data access component. The component retrieves a single topic record from the data storage and returns the correct message format to the user interface.

Public Function gettopicrecord (byval ID as integer) as messages. topic dim t as messages. topic = new messages. topic Cn = new sqlconnection (secureconnectionstring) Cd = new sqlcommand ("gettopic", CN) CD. commandtype = commandtype. storedprocedure CD. parameters. add ("@ ID", ID) CN. open () DR = CD. executereader () DR. read () with T. id = ID. title = DR ("title "). description = DR ("Description") end with return tend Function

The design document will include a series of classes and methods used to process various requests from the user interface, and detailed information about which stored procedure is called and what message format is returned. Similarly, we will discuss the details of this process in a later article about Data Access layers.

Web user interface

Finally, the user interface design document includes all user input and display required to complete various schemes. Generally, user interface documents include the details of the interface mechanism and graphic design elements that make the user interface unique. For example, the color scheme, Font, and overall page design are as important as the input name and number of entries used to obtain the correct data for search query.

To make the document concise, a detailed description of the mechanism is usually outlined in a document separate from the graphic design. This is what we will do in the example. In a later article, we will create a comprehensive user interface document and implementation solution, detailing the elements and related operations of each screen. In another article, we will deal with various aspects of the application's graphics, focusing on the use of Cascading Style Sheets as a visual service.

The following is a typical user interface description, which involves the "topic" editing scheme.

Topic input screen

The "theme" screen displays a thumbnail list of all the current theme (Theme ID and theme name), and an "edit" link is displayed next to each topic. Click the edit link to call the associated topic records and display them in a series of input boxes. "Title" and "Description" are editable, while "topic ID" is read-only. You can edit the title and description, and then press "save" to write changes to the data storage. The input is verified. Both are required. The title can contain up to 30 characters, and the description can contain up to 500 characters. After the update is complete, a response message indicating that the update has been confirmed is displayed. If the update fails, a message indicating the error status is displayed.

You can also delete existing topic records by clicking the "edit" link in the list, reviewing the details of the records displayed on the screen, and clicking the "delete" link. After deletion, a response message indicating that the update has been confirmed is displayed. If the update fails, a message indicating the error status is displayed. Note that you cannot delete topics associated with existing questions or answers.

In addition, you can add a new topic record by clicking the "new topic" link on the initial display screen. "Title" and "Description" are displayed (ID input is not displayed), and a "save" button is provided. The input is verified. Both are required. The title can contain up to 30 characters, and the description can contain up to 500 characters. After the update is complete, a response message indicating that the update has been confirmed is displayed. If the update fails, a message indicating the error status is displayed.

With the above description, you can easily implement a complete functional screen. The method to determine a good design document is: it enables the reader to complete the work without asking additional questions. The final user interface design document will include such descriptions for each screen in the application.

Summary and put into action

We briefly introduce the final design documents of the database, intermediate layer, and user interface implementation solution. Coupled with the architecture and initial planning documents, they form our complete design package. In practice, it takes at least a few hours to complete these documents, even for the smallest system. For large systems, it may take weeks or even months. Some people may be frustrated with this, but by doing this in advance, you can learn about almost all the major obstacles to completing the solution long before entering the coding stage of the project. This reduces the time required to write the actual code and reduces the number of errors and obstacles you may encounter.

Now, you have seen an example of how to create an application plan. You can start to consider how to use these elements in your work to improve the overall quality and productivity of the project. For more information about Project Planning and how planning affects software quality, see Steve McConnell's software project release Val guide.

Mike Amundsen provides training, presentation, and consulting services. For more information, see http://amundsen.com /. In addition, you can also find updates and related information on the http://www.amundsen.com/DotNetKB site.