After the physical architecture determines the logic 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.
Safety Planning Microsoft has a song of security and software: "Secure By Design, Secure By Default, And Secure By Deployment". 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 compiled 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 attacks 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. There is a common attack on the web application, which involves the user's script that users add client scripts in the input stream. This type of attack will perform additional dialogue and snug the user to send personal data to a 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. This is very important to take a point before entering the coding section of the project directly. 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).
