MBAPI model--an effort to unify standardization

MBAPI model--an effort to unify standardization

CQRS is about command and query separation. It classifies action into two types: command and query. And it is clear that "there is no Third kind".

In fact, blog Park bloggers are divided into two categories: one is the male blogger, a female blogger. There is no third type of blogger. It is much better to classify bloggers in a blog park as a two-way taxonomy than to classify action as command and query.

The above classification can also be described as: action is divided into two kinds, one is command, one is "non" command; blog Park of bloggers in two, one is male bloggers, one is "non" male blogger.

What is command? What is query? You do not have to pursue 100% correctly, using the familiar "method/method" to formalize command and query words. So all of the "no return" methods we have written are command, and all of the "return value" methods we have written are query. "There is no return value" and "non-Men and women" more like it. For example, a void SignIn (string loginName, String password) is written here, and this method is command, and AccountInfo Getaccount (string loginName) belongs to query. So what if someone wrote the AccountInfo Login (string loginnamem, String password) method? It can be thought of as a mix of command and query, command and query.

How do we model the command in the framework of implementing CQRS? So, for example, the above void SignIn (string loginName, String Password) command method can be modeled as follows:

public class signinaccountcommand:command{

Public Signinaccountcommand (String loginName, string password) {

This. LoginName = LoginName;

This. Password = Password;

}

public string loginname{get; private set;}

public string password{get; private set;}

}

Signinaccountcommand is exactly the same as the Signin method, which is a complete description of one thing and provides a complete input for ' do '. LoginName and password are inputs. Signinaccountcommand successfully targeted the Signin method and had no loss of information at all. It is worth noting that the input in the command and the output in the event should be read-only and immutable.

Let's take a look at the "Gang of Four" command mode:

Command: A logical object that encapsulates the processing of client requests. These objects can be immediately

execution, entering queues, saving, and logging for deferred processing.

Command message: Messages that identify the logical operations that the client needs to invoke. The command message is also

These operations provide input data.

The command completely describes one thing and provides a complete input for doing it. When we use imperative programming languages like C # to write programs, we are writing commands. For example, there is a function table in our RDB, a managedfunction table referencing the function table, and a rolefunction table referencing the Managedfunction table. What do we do when we write the logic of deleting a function entity using C # in the data access layer or the Application service layer? The following three commands can be used to express: Deleterolefunctioncommand,deletemanagedfunctioncommand and Deletefunctioncommand. These three commands can be executed in a sequential order.

public class signinaccountcommand:command{

Public Signinaccountcommand (String loginName, string password) {

This. LoginName = LoginName;

This. Password = Password;

}

public string loginname{get; private set;}

public string password{get; private set;}

}

With

void SignIn (String loginName, string password) is equivalent. But creating a command class for each of these commands doesn't look like a best practice. There should be a better equivalent of the way the command is expressed. Can you do that? Introduce a few simple concepts and then give a "shape" based on the understanding of these simple concepts. This form should be used to express any command. Now we can describe the Signin method like this:

ontology= "Account"

verb= "SignIn"

infoid=[{' key ': ' LoginName ', ' value ': ' Anycmd '}]

infovalue=[{' key ': ' LoginName ', ' value ': ' Anycmd '},{' key ': ' Password ', ' value ': ' 123456 '}]

It seems to be possible, because with the above four lines we have also completely described the signin command and provided complete input for execution. This form of the above is not too difficult to understand, compared to the HTTP request document there is no essential difference. Ontology + infoid = Uri,verb = Httpmethod,infovalue = Httpcontent.

Now that you can use HTTP to describe the command, why do you propose a new form? There is an answer in this immature essay.

Ontology, verb, infoid, infovalue are the elements of command, and there are some auxiliary elements, as shown in:

The use of "form" to fill in the bearer of "information" data can be described in the universe all things.

There are three types of message: Action, command, event. The three are not further differentiated in the structure of the data transmission object, the structure of the three is identical.

Timestamp : All three have a timestamp attribute, the difference is that the timestamp of "action" comes from the current universe context; the timestamp of the command is filled by the client, but the execution time of the command is determined by the server; the timestamp of the event is often past and filled by the client.

execution Nature: The server immediately executes a command with the type of action requested, arbitrarily executing a command of the requested type ("discretionary" refers to when execution is performed by the server, such as late to Night execution), The command to handle the request type event is also determined by the server (for eventSourceType, Eventsubjectcode, and statecode programming).

The server has only one service to send and receive these three kinds of message:

Message can fully describe any one thing and provide complete input for doing, the service Inputmodel and Outputmodel type is a message, the function is complete.