Asp. NET application planning and Design (3)

Asp.net| Program | planning | Designing physical Architecture

After the logical layer is identified, it is also important to consider the physical layer. For example, you can implement this application on a single actual computer that has SQL Server, Internet Information Server, asp.net, and. NET runtime installed at the same time. This will be a physical layer. But a more reliable and scalable approach is to deploy a Web form on a cluster of three Web servers, deploy the. NET component assembly on two application servers, and deploy the database on two recovery-mode SQL Server. The resulting physical architecture includes seven Windows servers in three primary groups: Web clusters, component clusters, and database clusters. If you understand that different logical parts of your system can be located on different computers, you may implement different code.

For our example, we employ an effective and powerful two-tier model: The WEB server managed user interface and components, and the database server hosts the SQL Server data store. If traffic is very large, this model gives us the flexibility to add more servers to the cluster and keep it simple enough to handle. The following image shows the mapping relationship between this physical architecture and the logical architecture defined earlier.


Figure 2: Mapping between a physical architecture and a three-tier architecture

As you can see, the logical architecture and physical architecture do not have to be the same. In the planning phase there is one more element to consider: security.

Security Planning

Microsoft has a mnemonics on the subject of security and software: "Secure by, security by default, and secure by deployment (design security, default security, and Deployment safety)". That is, design in security, expect the system to be safe by default, and create solutions that can be deployed successfully in a secure environment. Security is always important. Since more and more software is going to "survive" on the public Internet, writing secure software is even more critical. Fortunately for us, the. NET runtime and the Windows operating system provide a wide range of security options and features that we can easily include in our applications. Instead of focusing too much on identifying and eliminating the details of vulnerabilities in online solutions, we can point to some of the most common vulnerabilities and point out how our application planning is handled.

Note: For more information about the available options, see Microsoft Security Developer Center.

Buffer overflow

This may be the most common security vulnerability in a compiled application. Because we will use the. NET runtime, which is designed to run safely in memory, it is unlikely that a buffer overflow can occur. In addition, we encode the solution using Microsoft Visual Basic?. NET and Microsoft Visual Basic?. NET is not as vulnerable to buffer overflow problems as C or C + +. However, even if we intend to create components in C + +, we can also use the special features of the compiler, GS conversion, to protect us from most buffer overflow attacks.

Database attacks

Another common security vulnerability could allow a malicious user to gain access to the raw data stored in the database. To prevent hackers from gaining control over data, we use only SQL Server stored procedures instead of inline queries. This can greatly reduce attacks that attempt to insert additional SQL commands into the input stream. We also use input validation in multiple locations in the program to ensure that all input contains only valid characters.

Cross-site scripting attacks

Another common attack on Web applications involves users adding client script to the input stream, which will perform additional conversations and trick users into sending personal data to their own web site. To solve this problem, we use a new feature of ASP.net 1.1 to filter out all input of this malicious code and prevent it from being placed into the system. The display screen also contains additional code that automatically disables any script or displays the markup that may be inserted into the data store.

At this point, we have obtained the logical model and physical model of the application, as well as the list of security features that the implementation solution contains. With these and the target statements and user scenarios, we can start the last part of the "pre-coding" adventure.

Complete the design document

It is important to take a moment 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. In the following articles, we will describe in great detail how to implement these components. But for now, we're just sketching out the rough outlines of each component, discussing the most important aspect of the process, 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. We will discuss the details of the database in the next article. 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.