Mike Amundsen
August 2003
Applicable to: Microsoft? ASP.NET
Summary: Learn how to plan and design ASP.NET applications. This article uses a knowledge base web application as an example to discuss the most common factors in practical application creation practices. (This article contains some links to English sites.)
table of Contents
Introduction Planning Basic ASP.NET App Defining Application Architecture Security Plan Complete Design Document Summary and Putting
Introduction
Welcome to "Enter the ASP.NET World". In the next few weeks or months, this series will gradually introduce how to use Microsoft? ASP.NET and Microsoft Visual Studio .NET to design, implement and deploy typical web applications to explore the actual application creation. Several factors in practice. We don't just place some web forms, nor is it limited to only have some data bindings on the backend database. Data binding and web form layout are important, but there are many other problems.
For example, no matter what target platform or language, all well-encoded projects include some basic planning steps, such as target declarations, user program documents, and even architectural documents for identifying physical boundaries and logical boundaries of solutions. In addition, the security plan is included in the early days of the solution lifecycle. It is a very good habit. These contents are designed with a good database model, a well-designed middleware component, and a concise user interface design, ensuring that the application you finally deploy in production is safe, reliable, and user friendly.
At this point, some readers may think that this article belongs to a highly high-tech article, and the target is targeted in some super large enterprise programs, and this solution is not suitable for general small factories, enthusiasts, or personal development groups. Actually, not this! Even if you just create a web-based small solution that yourself use, a perfect plan will help ensure the final easily and deployment of the process. Moreover, these techniques can not be used for advanced programmers or Web developers. Whether your technical level is, no matter which type of target reader you belong, I believe you will find this series of articles to you, it provides you with rich information, and (please let me say this) is very interesting .
We will generate a sample knowledge base Web application called DotNetkb, which will run through the entire series. In this article as the first article, we will introduce the design phase of the typical project, including basic planning, application architecture and implementation. After learning this article, you will already have all documents and will not wait to start creating solutions.
The preparatory work is very simple, we skip this part of the content, start the first step "application plan".
Planning basic ASP.NET applications
The first step in creating a web-based ASP.NET application using Visual Studio .NET is to develop basic application planning (APs). The development plan is essential not only for large solutions established by multiple developers, but even for minimal applications, a perfect AP is also very important. Creating an AP helps you can consider some common problems carefully when you start coding ". This way, you can fully understand challenges and solutions in the early days of the application lifecycle, rather than discovering problems after fully fell into a dilemma. In the book "Software Project Survival Guide", the author Steve McConnell pointed out that the former may be the latter 50 compared to the cost of correcting errors in the later stage of the software project and the cost of finding and correcting these errors in the early stage. 200 times.
What is the content of a perfect project plan? Many content can be included, but the most basic is to include the target declaration and a series of user solutions. There are many other useful materials, including demand documents, coding standards, delivery progress, testing processes, etc. For the simple sample solution we have to build, you will mainly introduce a simple application declaration and some user solutions. Other issues will also be solved. Application declaration
This series of articles to be established (called DOTNETKB) is a simple knowledge base Web site. In this site, users can improve various issues and can be authorized to answer. Thus, the next time the visitor finds a solution to the common ASP.NET problem, search and filtering the resulting result data.
This is a basic target statement for our DotNetkb project. DotNETKB is a web-based application that lists a series of issues proposed by visitors and displays reply to these issues. Visitors can add new issues to the system, and can search and filter these issues in accordance with the keywords, questions, and / or answers. Visitors can also sort the questions list by topic or by adding the date added to the system.
Authorized experts can log in to the part of the installed security mechanism, review issues, add, edit, and delete one or more answers to a question. Application administrators can also create expert login permissions and login profiles, as well as add, edit, and delete problem topics.
In addition, some basic statistics, including problems and answers in the system, and the number of responses to each expert and the number of pages that have been accessed.
As you can see from the above statement, the solution is very simple. When reading a target statement, you may start thinking about many other features that can be added to this application so that the application is more powerful. This shows a major basis for project objectives, that is, avoiding "function spread". We are all clear that if the change in the final result is originally based on the concept, the simple idea will result in a very large and distorted result. There is an old saying: "If you don't know where to go, you may stop in a place", it originally revealed that the summer road travel, the truth can also be used for software projects.
More information may be needed in some project target statements. And for our use, the target statement above meets the requirements. Now that we have a clear understanding of the application to be completed, some detailed information is needed to describe how the user interacts with the system and which tasks need to perform to complete the goal. We need a range of user programs.
Documentation user program
The user program is not amazed. Usually, they just describe how users interact with the application. The key value of the user program is to record the idea of how everyone wants how the user wants to run and how the application should respond. By completing this process, you will fully understand the data points and functions required to process various users and systems interact. In other words, writing a perfect user program will help you determine the database, middleware, and user interface elements that complete the solution needs to be implemented.
Note: Visual Studio .Net Enterprise Architect has a very nice function that allows you to use Microsoft Visio? Create a user program via UML (Unified Modeling Language) and then generate basic code of these scenarios. Here, I don't plan to discuss these details, but can you find a good article on this topic at the MSDN? Academic Alliance site
Generating .NET Code Using Visio Enterprise Architect's UML, the author is SREEDHAR KOGANTI.
After the target statement on the previous section, the following is several example user solutions for the DotNetkb project.
Search knowledge base
Anonymous users can enter one or more keywords and perform searches, and the search will return issues and / or answer lists that contain these keywords. Users can lock keyword search only in searching, only searching or both search. The returned list will display the number of questions and its reply and the number of times accessible by other users. Click the link to return a reply (plain text) list in reverse order in advance. Enter new issues into the knowledge base
Anonymous users can browse the screen to enter new issues to the database for licensing experts to review and reply. The user can enter the title and content of the problem, and you can choose to record the problem under a topic in a series of topics. Users can also enter their names and related URLs (emails, web addresses, etc.). The input will be verified to ensure that the required data is included and ensures that all input data will not be subject to script attacks. Once the data is verified and saved to the database, the user will see a response screen, thank the user's support and connect the user directly to the home page. In addition, users can also choose to "remember" their name and URL use it after you have access to this site.
You have already understood its working principle, right? Each program tries to refine the important aspect of the user interaction. For example, the two scenarios listed above indicate that the user is "anonymous" (anonymous), which means that such users do not need to log in or otherwise authorized. The second example also identifies several input values, verification steps, and optional operations.
Of course, this is just two examples; the complete system requires more options. In addition, special attention is that "user" is not only a person, or it can be other applications that you need to communicate with it, or even other parts of your application. For example, a scenario description home page lists the most recently added to the knowledge base for anyone to view. The "user" in this example will be the home page itself. There are also some solution description experts to find and respond to new issues and how administrators update the topic list and manage the other parts of the system. I have identified more than 20 programs for discussing this simple application. You can find current lists (all other information related to this item) in DotNetkb.
EXAMPLES So we have a goal statement and some user programs. Now, it's time to learn some technology. We need to define an application architecture, which can help us actually implement a "fresh and effective code".
Define application architecture
With the basic purpose and for the list of users scheduled to develop users, you need to start planning the entire architecture. The main goal is to identify logic aspects and physical aspects of applications, how to split applications into a variety of useful parts. Safety aspects have also been added in this section. Safety is the "first start" of the plan, instead of "final adding" in the development cycle. We will discuss this issue later in this section later.
Logical architecture
Logically, you need a planning solution to identify the "boundary" between data storage, data access, business rules, user interface, etc. Typically, the Web developer selects a two-stage model and stores all the code for accessing existing data storage systems (such as Microsoft SQL Server) with a web form. A more efficient method is to create an intermediate layer component library located between the web form user interface and the SQL Server data storage system. This three-layer method (web form, component, database) is usually required for most applications. However, in some cases, one other layer may be required to process data transmitted between the server. This transport layer can be implemented using a platform-independent protocol (such as XML-SOAP). However, if you use Microsoft .NET technology from head until tail, you can use the .NET remote protocol's binary to complete this task, and the speed is much faster than using XML-SOAP.
For our example, we will define three logical boundaries: user interface (web form), intermediate layer (one .NET component assembly), and data layer (SQL Server database). Figure 1 shows how to represent this. Figure 1: Three-layer map
Now we have a simple logical model. How does it work? It helps us consider the boundaries between individual logical groups. Each logical layer should be as independent as possible with other layers. Ideally, the changes in the layer should have a minimum impact on the overall. For example, if you change data from SQL Server to an XML data file, the only layer that is affected should be an intermediate layer layer. The user interface should not consider changes at all. This will make you think: how to implement the actual encoding of the solution to achieve this.
In addition, the logical layer helps us consider security issues. There is a potential security vulnerability between the boundaries between each layer. Moreover, each layer may have its own specific security measures (SQL Server permissions, .NET runtime permissions, ASP.NET security, etc.). Similarly, we will discuss this issue later in this section later.
Physical architecture
After determining the logical layer, it is important to consider the physical layer. For example, you can implement this application on a single actual computer with SQL Server, Internet Information Server, ASP.NET, and .NET, and .NET, and .NET. This will be a physical layer. But more reliable and scalable methods are: deploying a web form on a cluster consisting of three web servers, deploying a .NET component assembly on two application servers, deploying a database on two failed recovery modes . The physical architecture thus produced will include seven Windows servers in three main groups: web clusters, component clusters, and database clusters. If you understand the different logic components of the system can be on a different computer, you may implement different code.
For our example, we use an effective and powerful two-layer model: web server hosts user interface and components, database server hosts SQL Server data storage. If the traffic is very large, this model allows us to flexibly add more servers in the cluster and keep it sufficiently simple to process. The following image shows the mapping relationship between this physical architecture and the previously defined logical architecture.
Figure 2: Mapping relationship between physical architecture and three-layer architecture
As you can see, the logical architecture and physical architecture do not have to be the same. Consider one content in the planning phase: security.
Security plan
Microsoft has a song about security and software this theme: "Secure by Design, Secure By Default, And Secure By Deployment (design security, default security, and deployment security)". That is, in a secure design, the expectation system is secure by default, as well as a solution that can be successfully deployed in a secure environment. Safety is always important. Since more and more software wants to "survive" on a public Internet, write secure software is more critical. For us, fortunately, .NET runtime and Windows operating systems offer a wide range of security options and features, we can easily include it in our application. There is no need to pay too much attention to the details of security vulnerabilities in online solutions, we can point out some of these most common vulnerabilities and point out how our application planning is processed.
Note: For more information on available options, see
Microsoft Security Developer Center.
Buffer overflow
This may be the most common security vulnerability in the compilation application. Since we will use .Net runtime, it is designed to be safely running in memory, so it is unlikely to overflow. In addition, we encode the solution using Microsoft Visual Basic? NET, and Microsoft Visual Basic? NET is not as possible to be affected by buffer overflow as C or C . However, even if we intend to create components with C , we can also use the special features of the compiler, GS conversion, to protect us from the attack overflow from most buffers. Database attack
Another common security vulnerability may enable malicious users to access privileges for raw data stored in the database. In order to prevent hackers from obtaining data control, we only use the SQL Server stored procedure without using "Inline Query". This makes greatly reduce the attack attempt to insert another SQL command in the input stream. We also use input verification at multiple locations in the program to ensure that all inputs contain only valid characters.
Cross site script attack
There is another kind of common attack on the web application, which involves the user's ability to add a customer script in the input stream, which will execute additional dialogue and snug the user to send personal data to the hacker's own Web site. To solve this problem, we use A new features of ASP.NET 1.1 to filter all the inputs of this malicious code to prevent it from being placed in the system. The display screen also contains additional code, which will automatically disable any scripts or displays that may insert into the data store.
At this point, we have obtained the logical model and physical model of the application, and to ensure that the implementation list is included. With these and target statements and user programs, we can start the last part of the "pre-encoding" adventure.
Complete design documentation
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. In the following articles, we will introduce how to implement these components very detailed. But now, we just sketch the rough 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. We will discuss in the next article. 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.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 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.
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 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 returnit 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.
In the next article, we will discuss the details of the data storage system using Visual Studio .NET in SQL Server. We will define the data table, create the required stored procedures, and set the correct data access to ensure a secure and reliable connection between any component and the data itself.
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.
Mike Amundsen provides training, speeches and consulting services. To understand his details or contact him, visit his site http://amundsen.com/. In addition, you can find updates and related materials in this article on http://www.amundsen.com/dotnetkb site.
