Asp.net| Planning | It is important that you take a little time to actually sketch out the logical components of your application before you go directly to the coding part of the project. In our sample solution, we want to implement the three logical components of the solution: the database, the. NET data access component, and the ASP.net user interface. Now, let's sketch out the outline of each component and discuss the most important aspect of the process, namely, the interaction between the documented components.
Database
For DotNetKB applications, we need to store the data in three tables: topics, questions, and answers (see the figure below).
Figure 3: Topics, questions, and Answers table
We need to use stored procedures so that middle-tier components can also access data securely. Here, we just point out that the database document that lists the table name and all the column details, the default index, and the list of stored procedures 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 section.
Note: If you take heed, you may notice that we have not mentioned storing expert data in the database. Just 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 Components
The data access component design document depicts all the details of the interaction with the data storage system and the interaction with the user interface. In some systems, the data access component is actually multiple assemblies that handle various problems in the process. For example, there may be a series of business rules that are presented in a completely separate user interface from data storage and retrieval. In this case, it might be wise to separate the business component from the data access component.
In our example, the actual implementation is two separate components: the message component and the DataAccess component. This message-oriented implementation will be particularly effective if you plan for a transport service that supports xml-based data, such as a SOAP Web service.
Message components
A message component defines a series of classes that are used to transfer data between layers. These messages can exist as binary or XML text data. The value of a message layer is to protect the rest of the system from the specifics of the data store implementation, such as SQL Server, XML files, and so on. In addition, by implementing message layers rather than more complex "smart objects" libraries, our solutions can more easily support remote invocation services that cannot send data and class-level logic at the same time, such as Xml-soap.
The following is an example of a message class that implements the Topic message and its collection in this example:
Public Class Topic private _id as Integer private _title as String private _description as String public Prop Erty ID () As Integer get return _id end Get Set (ByVal Value As Integer) _id = V Alue End Set End Property public Title () as String get return _title end Ge T set (ByVal value as String) _title = Value End Set End Property public Property Descriptio N () As String get return _description End Get Set (ByVal Value as String) _DESCR Iption = 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 Functi On ADD (ByVal s as Topic) As Integer return List.add (s) End Function public Sub Remove (ByVal Index As Integer) List.remove (Inde x) End SubEnd Class
Note: If you have tried a 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. Luckily, the. NET runtime knows how to do this without having to do too much work. However, when we are learning articles that create messages, we will discuss in detail how the. NET Runtime serialized classes and how we do things to optimize the processes in our code.
When you implement message components and data Access Components later, the article describes the details of this method. The design document will contain a list of all the information and its attributes and data types. Now, we're just thinking about how to use this message method to encapsulate data transfer between layers, and how to create a common data service that is used in conjunction with local and remote scenarios.
Other data Access Components
Once the concept of a message class is defined, the data access component can focus on the details of the direct conversation with the data storage system and return the information in the correct message format. In our example, this involves mapping SQL Server stored procedures using requests from the user interface and creating messages (or message sets) that can be returned to the user interface for display.
For example, the following is a sample code that is part of a data access component that retrieves a single Topic record from the data store 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 and return tend Function
The design document will include a series of classes and methods for handling individual requests from the user interface, with detailed information about which stored procedure is invoked and what message format is returned. Again, we'll discuss the details of this process in a later article that mainly introduces the data access layer.
Web user Interface
Finally, the user interface design document will include all user input and display required to complete the various scenarios. Typically, user interface documents include details of the interface mechanism and graphic design elements that render uniqueness to the UI. For example, the color scheme, font, and overall page design are as important as the input name and number of inputs used to get the correct data for a search query.
To make your document concise, you typically outline the details of the mechanism in a separate document from the graphic design. This is the work that we will do in the example. In a later article, we'll create a comprehensive user interface document and implementation that details each screen's elements and associated operations. In another article, we'll deal with all aspects of the application about graphics, focusing on the use of cascading style sheets as a façade service.
The following is a typical user interface description, which involves the topic editing scheme.
Theme Input Screen
The Themes screen displays an abbreviated list of all the current topics (subject ID and subject name), and an edit link appears next to each topic. Clicking the edit link invokes the associated subject record and displays it in a series of input boxes. The title and description are editable, and subject ID is read-only. Users can edit the title and description, and then press the Save button to write the changes to the data store. The input will be validated. Both are required entries, the length of the title is limited to 30 characters, and the length of the description is limited to 500 characters. When the update is complete, a response message indicates that the update was confirmed, and if the update fails, a message indicates the error condition.
Users can also delete existing subject records by clicking the Edit link in the list, auditing the details of the record on the screen, and then clicking the Delete link. When the deletion is complete, a response message indicates that the update was confirmed, and if the update fails, a message indicates the error condition. Note that users cannot delete topics that are associated with existing questions or answers.
In addition, users can add a new topic record completely by clicking the new theme link on the initial display screen. The title and description input (no ID input) is displayed and a Save button is provided. The input will be validated. Both are required entries, the length of the title is limited to 30 characters, and the length of the description is limited to 500 characters. When the update is complete, a response message indicates that the update was confirmed, and if the update fails, a message indicates the error condition.
With the above description, you can easily implement a complete functional screen. The way to judge a good design document is that it enables the reader to complete the work without presenting additional questions. The final user interface design document will include this type of narration for each screen in the application.
Summary and put into action
We briefly introduce the final design document of the database, middle tier and user interface implementation scheme. Together with the architecture and initial planning documents, they form our complete design package. In the actual case, even the smallest system, the completion of these documents will take at least a few hours. For large systems, it may take weeks or possibly months. Some people may feel a little frustrated with this, but by doing this beforehand, you can learn about almost all the major obstacles to completing the solution before you enter the coding phase of the project. This reduces the time it will take to write the actual code and also reduces the number of errors and obstacles you may encounter.
Now that you've seen an example of how to create an application plan, you can start thinking about how to use these elements in your own work to improve the overall quality and productivity of your project. For more information about project planning and how you plan to impact the quality of your software, see the software project Survival Guide of Steve McConnell.
