This is very important to take a little time to actually select the logical component of the application. In our sample solution, we want to implement three logical components of the solution: database, .NET data access component, and ASP.NET user interface. Now, let's take out the general outline of each component, the most important aspect of the discussion process, that is, the interaction between documentation components.
database
For DotNetkb applications, we need to store data in three tables: topics, questions, and answers (see below).
Figure 3: Theme, problem and answer sheet
We need to use stored procedures to allow intermediate layer components to securely access data. Here, we just point out: List the table name and all column details, the default index, and the database document of the stored procedure list, which should be included in a complete database design document. That is, the documentation should have the details required to successfully implement the system data storage section.
Note: If you pay attention, you may notice that we did not mention that stored expert data in the database. Just to make the project more interesting (usually give us a chance to use direct XML data storage), we store expert information in an XML data file.
Data Access Components
Data Access Components Design document depicts the interaction with the data storage system and all details with the interaction with the user interface. In some systems, data access components are actually multiple assemblies of various issues during processing. For example, there may be a series of business rules that present on a fully independent user interface with data storage and retrieval. In this case, the implementation of the business component and the data access component may be wise.
In our example, the actual implementation is two separate components: Message components and DataAccess components. If you plan to support a transport service based on XML-based data, such as SOAP Web Service, this-oriented implementation will be particularly effective.
Message component
Message components define a series of classes for transmitting data between layers. These messages can be present as binary or XML text data. The value of the message layer is that the rest of the protection system makes it independent of the specific details of the data storage implementation scheme, such as SQL Server, XML file, and the like. In addition, by implementing a message layer rather than a more complex "Smart Object" library, our solutions can easily support remote call services that cannot simultaneously send data and class level logic, such as XML-SOAP.
Below is a message class example, implemented Topic messages in this example:
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 Property
END CLASS
Public Class Topics
Inherits System.Collections.CollectionBaseDefault 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 Sub
END CLASS
Note: If you have tried the design of the message, you will know what we want to make these message classes to be sent back and forth between the application layer. Fortunately, .NET runtime knows how to do this, without our work. However, when we learn to create a message, we will discuss how .NET runtime, how to set the class, and how we will operate to optimize the process in the code.
This method will be described in the article when the message component and data access component are implemented later. The design document will contain a list of all information and its properties and data types. Now, we just consider how to use this message method to encapsulate data transmission between the layers, how to create a regular data service that works with the local program and remote scheme.
Other data access components
After defining the concept of the message class, the data access component can focus on the details of the direct conversation with the data storage system, and return information in the correct message format. In our example, this will involve mapping the SQL Server stored procedure using requests from the user interface, and creates a message (or message collection) that can be returned to the user interface.
For example, the following is a part of the sample code of a data access component, which 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 message.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 T
END FUNCTION
The design document will include a series of classes and methods for processing each request from the user interface, and contains which stored procedure and returning to what message format. Similarly, we will introduce the details of this process in the following articles that mainly introduce the data access to the layer.
Web user interface
Finally, the user interface design document will include all user input and display required to complete various scenarios. In general, the user interface document includes details of the interface mechanism and a graphic design element that exhibits uniqueness in the user interface. For example, color matching schemes, fonts, and overall page are designed, as important as input names and input quantities for obtaining the correct data of search queries. To make a concise document, you usually describe the details of the mechanism in a document with a graphic design. This is what we will do in the example. In an article later, we will create a comprehensive user interface document and implementation, detail the elements and related operations of each screen. In another article, we will handle all aspects of the application, focus on the use of cascaded style sheets as an appearance service.
Here is a typical user interface description, which involves the "Topic" editing solution.
Topic input screen
The Theme screen will display a thumbnail list of all current topics (topic IDs and theme names), and a "editing" link will be displayed next to each topic. Clicking the Edit link will call the associated topic record and display it in a range of input boxes. "Title" and "Description" are editable, and "theme ID" is read-only. Users can edit the title and description, then press the "Save" button to write the change to data storage. The input will be verified. Both are the required inputs, the length of the "Title" is limited to 30 characters, and the length of the "Description" is limited to 500 characters. After the update is complete, a response message indicates that the update is confirmed; if the update fails, a message indicates an error condition.
You can also delete an existing topic record, and the method is to click the "Edit" link in the list. After reviewing the record details on the display screen, click Remove link. After the deletion is complete, a response message indicates that a confirmation update; if the update fails, a message indicates an error condition. Note that users cannot delete the topics associated with existing issues or answers.
In addition, the user can add a new topic record in full, and the method is to click the New Topic link on the initial display screen. The "Title" and "Description" input (not displayed) are displayed and a "save" button is provided. The input will be verified. Both are the required inputs, the length of the "Title" is limited to 30 characters, and the length of the "Description" is limited to 500 characters. After the update is complete, a response message indicates that the update is confirmed; if the update fails, a message indicates an error condition.
With the above description, you can easily implement a complete feature screen. It is to determine a good design document that it enables the reader to complete work and will not present additional problems. The final user interface design document will include such narratives in each screen in the application.
Summary and put into action
We briefly introduce the final design document of the database, intermediate layer, and user interface implementation. Plus architecture and initial planning documents, they have formed our full design package. In actual case, even a minimum system, it takes at least a few hours. For large systems, it may take several weeks or even a few months. Some people may have a bit of frustration, but by completing these work in advance, you can understand almost all major obstacles to completing the solution very early before entering the code. This reduces the time to write the actual code, and can also reduce the number of errors and obstacles you will encounter.
At this point, you have seen a available example of how to create an application plan, you can start thinking how to use these elements in your own work to improve the overall quality and productivity of the project. For more information on project planning and how to affect software quality, see Steve McConnell's Software Project Survival Guide.
