A more reasonable solution to allow the client to get intermediate process information in a lengthy server-side event

A more reasonable solution to allow the client to get intermediate process information in a lengthy server-side event

I think the solution to the long server-side event, which gives the client access to intermediate process information, is unreasonable and technically misused, and the full Ajax Word can easily mislead readers.

Original demand:

b/S structure of the system, the user point a button system began to send thousands of messages, request to send information (send success, number of failures, remaining quantity ...) Dynamic real-time feedback to the customer.

The technical misuse of the original text:

(1) Ajax,pageload These UI layers are infiltrated into the logic layer.

(2) Too much responsibility for thread

It's not that the multithreading on the Web page is bad, but web development has been going on for a long time, the basic OO design capability is down, or the OO design is simply ignored, only the page is in the eye.

In the case of the original text, you don't think of it as web development, and everything becomes simple.

My solution:

First, there must be a class that manages each piece of information.

Public abstract class Messageholder
{public
DateTime sendtime {get; set;}
Public String Receivermail {get {return receiver.mail;}}
Public String errormessage {get; set;}
Public Int32 Sendcount {get; set;}
Public Boolean sendexpired {get {return sendcount > 5;}}
Public Boolean Sendok {get; private set;}
Public Guid Id {get; private set;}
Public String Sendresult {got
{
if (Sendok) return "sent successfully";
else
{
if (sendexpired) return "Send Failed";
else return "wait to send";
}}} public
class Mailmessageholder:messageholder
{
Pub　　　　Lic String Title {get; private set;}
Public String Text {get; private set;}
}