Asp. NET application planning and design (4)

asp.net| Programs | planning | Designing 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 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.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 Sub

End 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.

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 With
Return T
End 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.

In the next article, we'll discuss the details of using Visual Studio. NET to establish a data storage system in SQL Server. We will define the data table, create the necessary stored procedures, and set the correct data access to ensure a secure and reliable connection between any component and the data itself.