Asp. NET application planning and Design (2)

Asp.net| Program | planning | Designing a Document User program

There is nothing surprising about the user scenario. Typically, they simply describe how the user interacts with the application. The key value of a user scenario is to document the idea of how everyone expects the system to work and how the application should respond. By completing this process, you will be fully aware of the data points and functions needed to handle the various user interactions with the system. In other words, writing a sophisticated user scenario will help you determine the database, middleware, and user interface elements that you need to implement your solution.

Note: The Visual Studio. NET Enterprise Architect has a very good feature that allows you to use Microsoft Visio? Create user scenarios through UML (Unified Modeling Language), and then generate the basic code for these scenarios. Here, I'm not going to delve into these details, but can you do it on MSDN? Academic Alliance site found a good article on this topic generating. NET Code Using Visio Enterprise Architect ' UML, the author is Sreedhar Koganti.
With the goal declaration in the previous section, here are several sample user scenarios for the DotNetKB project.

Search Knowledge Base

Anonymous users can enter one or more keywords and perform a search that returns a list of questions and/or answers that contain these keywords. Users can lock keyword searches in search questions only, search answers, or both. The returned list displays the number of questions, their replies, and the number of times that they have been accessed by other users. Clicking the link returns a list of replies (plain text) sorted in reverse chronological order.

Enter a new problem into the knowledge base

Anonymous users can browse the screen used to enter new questions to the database for authorization experts to review and reply to. The user can enter the title and content of the question, and optionally record the issue under a topic in a series of topics. Users can also enter their name and associated URL (email, Web address, etc.). The input is validated to ensure that the necessary data is included and that all input data is not subject to scripting attacks. Once the data has been validated and saved to the database, the user will see a response screen, thanking the user for support and connecting the user directly to the home page. In addition, users can choose to have the site "remember" their names and URLs for later access to the site.

You already know how it works, right? Each scenario attempts to refine the important aspects of user interaction. For example, the two scenarios listed above indicate that the user is a "anonymous" (anonymous user), which means that such users do not need to log on or otherwise authorize. The second example also identifies several input values, validation steps, and optional actions.

Of course, this is just two examples; the complete system requires more scenarios. In addition, it should be noted that "users" can be more than just people, but also other applications that your program needs to communicate with, or even other parts of your application. For example, a scenario describes how the home page lists content that was recently added to the knowledge base for anyone to view. The "user" in this example will be the home page itself. There are also scenarios that describe how experts find and respond to new issues and how administrators update the list of topics and manage other parts of the system. I have identified more than 20 scenarios for the discussion of this simple application. You can find the current list (and all other information related to this project) in DotNetKB.

So far we have the target statement and some user scenarios. Now it's time to take a little rest and learn some techniques. We need to define the application architecture, which can help us actually implement the scenario with "Live and effective Code".

Defining the Application Architecture

With the basic purpose and the list of user scenarios developed for the solution, you need to start planning the overall architecture. The primary goal is to identify the logical and physical aspects of the application, that is, how to split the application into various useful parts. The security aspect is also added to this section. Security is the problem you need to consider at the start of planning, not the "last additions" in the development cycle. We will discuss this issue in detail later in this section.

Logical architecture

Logically, you need to plan your solution to identify "boundaries" between data storage, data access, business rules, user interfaces, and so on. Typically, a web developer chooses a two-phase model and uses Web forms to store all of the code used to access an existing data storage system, such as Microsoft SQL Server. A more efficient approach is to create a middle-tier component library that is located between the Web forms user interface and the SQL Server data storage System. This three-tier approach (Web forms, components, databases) is typically required by most applications. However, in some cases, you may need a different layer to handle the data transferred between servers. This transport layer can be implemented using platform-independent protocols such as XML-SOAP. However, if you use Microsoft. NET technology from beginning to end, you can do this using the. NET remote protocol's binary sedan, which is much faster than using XML-SOAP.

For our example, we will define three logical boundaries: the user interface (Web form), the middle tier (a. NET component assembly), and the data tier (SQL Server database). Figure 1 shows how to represent this content.


Figure 1: Three layer diagram

Now we have a simple logical model. How does it work? It helps us to consider the boundaries between each logical group. Each logical layer should be as independent as possible with the other layers. Ideally, changes in the layer should have a minimal effect on the whole. For example, if you change the data store from SQL Server to an XML data file, the only layer that is affected should be the middle tier layer. The user interface should not consider changes at all. This will allow you to think about how to implement the actual coding of the solution to achieve this principle.

In addition, the logic layer helps us consider security issues. There are potential security vulnerabilities in the boundaries between each layer. Also, each layer may have its own specific security measures (SQL Server permissions,. NET run-time permissions, asp.net security, and so on). Again, we will discuss this issue in detail later in this section.