WF framework programming (the first part is supplemented, and there is no impact on WF from the task table)

No task table pairWFImpact

In section 3.1, when considering task allocation, WF does not have the concept of a task table, and the WF engine does not care when the process is transferred or where it is transferred. This is so far. This design is very good, but WF does not provide a task table to deal with the retrieval of tasks, which has a great impact. It is necessary to discuss it clearly. To-Do task query: If we traverse the workflow instance and check whether the role of each activity is the current role, there will be serious performance problems. If you create a task table by yourself, consider the following two situations: 1. Specify a role during runtime. At this time, we can insert task information (workflow ID, assignment person, author...) at the application level... And so on), but if such a process runs not by WF but by the task table, it is equivalent to not using WF. In addition, the maintenance of the task table is very troublesome. After the task is executed, the task table should be updated and rolled back. The logic of the TAG should be frequently maintained at the business logic level. Rather, it is troublesome. Therefore, the maintenance of the task table must be completed by the workflow itself. This is also why we recommend that you use the custom acitivity method to maintain the task table. 2. Specify worlflowrole during design. In this case, the custom acitivity is used for maintenance task tables.

Question: 1. Is it necessary to implement the task table by yourself?

2. If you want to implement it by yourself, is the method in this article feasible or better?

I hope that those who study WF in the garden will give their valuable opinions.