Csla framework command object understanding

I sorted out a small workflow application that was created some time ago.ProgramIts core functional block is a trial development using the csla framework. Today, I will give my personal understanding of the command objects in the csla framework.

As we all know, in the process of workflow development, it can be divided into process definition process, process running process and task tracking, especially in the process of process instance running, the main implementation can be summarized as process instance creation, task submission, task rollback, completion, CC, and so on. Each function has a certain degree of independence, in addition, most operations are handled once after the command is submitted. Based on this idea, you can use the command object of the csla framework to implement the above functions during implementation.

Different from other objects in the csla framework, it can be said that its basicCodeBlocks are the simplest of all object types. in the Code, only the code dataportal_execeut () for executing static factory methods and commands can exist in other objects, it is called by the outer class as an internal class, it can also be publicly used by all other code, and the command object is initialized on the client, therefore, you can initialize the command object and internal members on the client, or verify the validity of the data on the client before it is passed to the server. The method running on the server is only dataportal_execeut (). It can only calculate the number of data items, or call other N classes to implement this command operation, in addition, the operation results can be reflected in the field for the client to receive. The following is a simplified command object:

 
1:/// <Summary>
 

 
2:/// Distribute CC messages
 

3:/// </Summary>
 

 
4:[Serializable]
 

 
5:Public ClassSharenode: csla. commandbase
 

 
6:{
 

 
7:// CC node ID
 

 
8:Private Int_ Nodeid;
 

 
9: 
 

 
10:// List of users to copy
 

11:PrivateList <String> _ Login user;
 

 
12: 
 

 
13:PrivateSharenode (IntNodeid, list <String> Login User)
 

 
14:{
 

 
15:This. _ Nodeid = nodeid;
 

 
16:This. _ Login User = login user;
 

 
17:}
 

 
18: 
 

19:Public Static VoidExecute (IntNodeid, list <String> Login User)
 

 
20:{
 

 
21:Sharenode COM =NewSharenode (nodeid, Role user );
 

 
22:COM = dataportal. Execute <sharenode> (COM );
 

 
23:}
 

 
24: 
 

 
25:Protected Override VoidDataportal_execute ()
 

26:{
 

 
27:If(_ Nodeid =Null| _ Nodeid <= 0 | _ useruser =Null| _ Your user. Count <= 0)
 

 
28:{
 

 
29:Return;
 

 
30:}
 

 
31:Foreach(VAR itemIn_ Login User)
 

 
32:{
 

 
33:Sharenode DATA = sharenode. newsharenode ();
 

34:Data. ID = _ nodeid;
 

 
35:Data. Date = datetime. Now. tostring ();
 

 
36:Data. Users user = item;
 

 
37:Data. readdate = datetime. maxvalue. tostring ();
 

 
38:Data. State =False;
 

 
39:Data. type = sharetype. node. tostring ();
 

 
40: 
 

 
41:Data. Save ();
 

 
42:}
 

 
43:}
 

44:}
 

The above is a simple process CC function previously implemented by myself. The command object sharenode is instantiated by calling the factory method on the client, in addition, fields are initialized by calling the private constructor (the passed parameters can be verified before Instantiation to avoid initialization data errors only after the server side is reached ). Call the execute method of the instance to move the instance object. Call the dataportal_execute method on the server (or local) to implement the functions you need internally. Here is just a simple data operation. If complicated, the command object may return more complex object types, there may be more complex business code on both the client and server.

As you may feel, simply looking at it, it is just an entry to access remote code, just like calling one of the methods in WCF, but it can be seen from its name "command object, the author also treats commands as objects, as if they are implementing workflows. Each command can exist as a command object. The first thought is clear, no matter how complicated code is implemented in the command object. It may be worth noting that if you operate the Database Multiple times during command execution, you need to mark the object method as a transaction attribute, just in case.

Each type of object in the framework has its usage conditions, such as this command object, which can be used to handle command operations.

Of course, this usage is taken into consideration from the perspective of using this framework. In addition, there are many ways to achieve this, and different scenarios may not be suitable for a framework. Or that sentence, it is used to learn more knowledge during use.

Note that in the framework, all business objects, including condition objects, must be identified as serializable! This is what I want to mark in the use of common classes...