Asp.net zookeeper (2)

V. ASP. NET Several Methods for passing values between two pages
ASP. NET provides an excellent event-driven programming model, allowing developers to simplify the overall design of the application, but this also causes some inherent problems, such as the use of traditional ASP, by using the POST method, we can easily transfer values between pages. Similarly, when using the event-driven programming model ASP. net is not that easy. Of course, we still have some methods to implement the same function. This article will try to solve this problem using different possible methods, but it is foreseeable that this article will include the querystring, session variable, and server. Transfer Method for cross-page value transfer.

Querystring
Using querysting to pass values between pages is already a very old mechanism. The main advantage of this method is that it is very simple to implement, however, its disadvantage is that the passed value is displayed on the address bar of the browser (Insecure), and the object cannot be passed, however, this method is a good solution when the number of transmitted values is small and the security requirements are not high. The steps for using this method are as follows:
1. Use the control to create a web form (Form)
2. Create buttons and link buttons that can return the form
3. Create a character variable to save the URL in the button or link button click event.
4. Add the querystring parameter to the saved URL.
5. Use response. Redirect to redirect to the saved URL above
The following code snippet demonstrates how to implement this method:
Source Page code:
Private void button#click
(Object sender, system. eventargs E)
{
String URL;
Url = "anotherwebform. aspx? Name = "+ textbox1.text +
"& Email =" + textbox2.text;
Response. Redirect (URL );
}
Target Page code:
Private void page_load
(Object sender, system. eventargs E)
{
Label1.text = request. querystring ["name"];
Label2.text = request. querystring ["email"];
}

Use session Variables
Using the session variable is another way to pass values between pages. In this example, we store the value in the control in the session variable and then use it on another page, to transfer values between different pages. However, it should be noted that storing too much data in the session variable will consume a lot of server resources, so you should be careful when using the session. Of course, we should also use some cleanup actions to remove unnecessary sessions to reduce unnecessary resource consumption. The general steps for transferring values using session variables are as follows:
1. Add necessary controls to the page.
2. Create buttons and link buttons that can return the form
3. In the Click Event of a button or link button, add the control value to the session variable.
4. Use the response. Redirect method to redirect to another page.
5. Extract the session value from another page. Clear the value explicitly when determining that this session is not required.
The following code snippet demonstrates how to implement this method:
Source Page code:
Private void button#click
(Object sender, system. eventargs E)
{
// Textbox1 and textbox2 are webform
// Controls
Session ["name"] = textbox1.text;
Session ["email"] = textbox2.text;
Server. Transfer ("anotherwebform. aspx ");
}
Target Page code:
Private void page_load
(Object sender, system. eventargs E)
{
Label1.text = session ["name"]. tostring ();
Label2.text = session ["email"]. tostring ();
Session. Remove ("name ");
Session. Remove ("email ");
}

Use server. Transfer
This method is a little more complex than the method described above, but it is particularly useful in inter-page value transfer, using this method, you can access the exposed value in the form of Object Attributes on another page. Of course, this method is used, you need to write additional code to create some attributes so that you can access it on another page. However, the benefits of this method are also obvious. In general, this method is concise and object-oriented. The entire process of using this method is as follows:
1. Add necessary controls to the page.
2. Create the get attribute process of the returned value
3. Create buttons and link buttons that can return the form
4. click the button to transfer the server. Transfer Method to the specified page.
5. On the second page, we can use context. the handler property is used to obtain the reference of the previous page instance object. With it, you can access the value of the control on the previous page.
The following code comprehensively implements the above steps:
Source Page code:
Add the following code to the page
Public string name
{
Get
{
Return textbox1.text;
}
}

Public String email
{
Get
{
Return textbox2.text;
}
}
Then call the server. Transfer Method
Private void button#click
(Object sender, system. eventargs E)
{
Server. Transfer ("anotherwebform. aspx ");
}
Target Page code:
Private void page_load
(Object sender, system. eventargs E)
{
// Create instance of source web form
Webform1 WF1;
// Get reference to current handler instance
WF1 = (webform1) Context. Handler;
Label1.text = wf1.name;
Label2.text = wf1.email;
}

Vi. ASP. NETApplication, Session, Cookie, ViewstateAnd CacheWhat are the differences between other variables?

Application is public and can be seen by all people, so it can be used for chatting rooms,

The session is private. Each client has a different session. The lifetime is normal for 20 minutes. You can set it to 1 minute or 2 hours.

A cookie is a file stored on the local machine. It records short information. It will always exist unless you make the cookie expire.

Viewstate is similar to the hidden control in ASP. It is used to record the status of the control in the page. It is mainly used when information is transmitted between pages,

Cache is a cache used to record some data that has been executed. For example, to read the database, it aims to accelerate the display and reduce the burden on the server. You can set the expiration time on your own,

VII. C #What is the difference between interfaces and classes?

1. interfaces are similar to classes, but they do not have execution methods. They are only a combination of methods, attributes, events, and index characters. They can only contain these four types of members; in addition to the four types of members, the class can also have other members (such as fields ).
2. An interface cannot be instantiated. An interface only includes the signature of a member, and a class can be instantiated (except abstract class ).
3. The interface has no constructor and the class has constructor.
4. The interface cannot be overloaded with operators, and the class can be overloaded with operators.
5. Interface Members do not have any modifiers, and their members are always public, while Class Members can have modifiers (such as virtual or static ).
6. The class derived from the interface must implement the execution method of all the members of the interface, but the class is not derived from the interface.
Why is there an interface? The main reason is that it is a valid contract. The class has some members, and they are not considered to be combined. The class is just a list with various methods, fields, and attributes, but in order to use the class in some way, you must know the functions that the class can execute. The specific operation is to declare the class that executes one or more interfaces. The class execution interface is derived from the interface, then, the execution method of all Members defined in this interface is provided.

8. What are the differences between processes and threads?

A thread is an operating system object that represents the path of the code to be executed in a process. Each Win32 application has at least one thread, which is usually called a live thread or a default thread. However, the application can freely create other threads to execute other tasks!
A process is a dynamic execution process of a program. It corresponds to a complete process from code loading, execution to execution completion. This process is also a process from process generation, development to extinction.
A thread is a smaller execution unit than a process. A process can generate multiple threads in its execution process to form multiple execution clues. Every thread, that is, every thread also has its own production, existence, and extinction processes. It is also a dynamic concept.
A program should have only one process, but it can have multiple threads.
It can be said that a running file can be called a process. But the process only exists in the memory. In fact, it will not do anything.
At this time, the thread is used. A thread is the executor of a program. A program has at least one thread, but more than one thread can exist in a multi-threaded operating system.

In fact, we can regard the thread as a queue for buying chicken and eating it (the loop queue is always arranged, knowing that I don't want to buy it and quit ). Everyone has the opportunity to get to the front of the team to buy things. This is like a thread, and they have the opportunity to be executed by programs. But when the thread really works, it is the time when we buy things at the front end of the team. This is the real execution stage of the thread.