Introduction to Enode Framework: Command Service API Design Idea

In the previous article, we introduced the physical deployment idea of the Enode framework. In this article we will briefly analyze the command service API design:

Command service is important in the Enode framework, where users use the Enode framework's main entry point is the command service. The UI layer, such as controller, sends a command to the command service, and the framework begins processing the command. Otherwise, command service is likely to be accessed with high concurrency. So what kind of API does command service provide?

What is the responsibility of command service first? Processing controller sent over the command, then how to deal with it? There are generally two kinds of general direction, that is, synchronous execution of command and asynchronous processing command; When synchronizing, the user wants the command to be fully processed before returning, reports an exception if any errors are encountered in the middle, and then controller catches the exception and then handles it later When a general user wants to know immediately whether the command has executed successfully, the command is executed in a synchronized manner. The command is processed asynchronously, and the user simply sends command to the command service, and then does not wait for command processing to complete. But the user may want to know what the command has done, so you need to provide a callback function that notifies the user that a command processing is complete, and the style of the general asynchronous programming has a callback function design. Based on the above analysis, Enode's Icommandservice interface is designed as follows:

<summary>represents a 

service to send or execute command.
    </summary> public
    Interface Icommandservice
    {
        ///<summary>send a command asynchronously.
        ///</summary>
        void Send (ICommand command, action<commandasyncresult> callback = null);
        <summary>execute a command synchronously.
        </summary>
        void Execute (ICommand command);
    }

The code should be very clear, it will not explain. If we pursue the fastest user availability, you can choose to execute the command asynchronously, call the Send method, or use synchronous execution command if you want the command to be done every time, that is, the Execute method The implementation principle of the synchronous Execution command in the framework is actually a synchronous control on an asynchronous basis,

Advantages:

Within the framework, the command processing process can be completely consistent, without the need for synchronous and asynchronous processing to design duplicate code, of course, we can do some abstraction to reduce duplicate code, but in fact this is more difficult;

Internal are asynchronous processing can be very convenient to implement the command of the retry mechanism;

Using ManualResetEvent to realize asynchronous synchronization, we can conveniently implement command's processing timeout control;

Because all of the command's processing is asynchronous, that is, all the command is queued for processing in a fixed queue, and the queue's consumer, the thread that handles the command, is configured when the framework is started, so access domain in The number of concurrent threads in the memory is controllable, so that we can reduce the likelihood of concurrent conflicts to some extent;

Disadvantages:

When a user invokes the Icommandservice.execute method to execute a command, his intention is to execute a command immediately and return the result, but we are not now dealing with the command immediately, but in the queue, The current thread is then jammed with ManualResetEvent, and then the current thread is allowed to continue to go down when the command processing is complete. Of course, if the command is slow to execute (the default is 10 seconds), is automatically timed out and then returned to the command initiator; the downside is that synchronization command may time out when concurrency is high, and for that, there is already a "high throughput" of how to improve the system in this blog post. , low latency, high availability "do a more detailed analysis of the ideas, have not seen the friends can go to see."