Windows Workflow Foundation (WF) is no longer a new Microsoft technology developed for creating and executing Workflows . However, at the moment it is not used very actively, and many developers have never heard of it. And my acquaintance with her happened relatively recently. While the use of WF in the implementation of certain categories of tasks may be more than justified. In this regard, I want to talk about the technology itself, its scope and consider an example of its use in the implementation of a specific project.
The key concept in WF is Activity (Activity) - a class that performs a unit of work in a WF runtime environment. The terms Work Flow and Activity are synonymous in the WF context. Each Activity performs an action - literally a program code (for example, in C #). Activities have input and output parameters, variables. An activity can be a composition of several child Activities, in which case, in the process of work, the parent Activity controls the launch of its child elements in the runtime environment in accordance with its internal logic. For example, Parallel Activity from the Base Activity Library (included in the .NET Framework package) launches child elements in parallel. And the If workflow, as it is not difficult to guess from the title, launches one of the two child elements, depending on the result of checking the specified condition.
Thus, ultimately, the creation of a work flow usually comes down to drawing up in the designer a flowchart based on the activities of the base library in conjunction with in-house activities. The workflow built in the designer is encoded in XAML (XML extension). The appearance of the designer is shown in the picture.
“Well, but what is it for me? - you ask. “I'd rather write a kilo of code than dig through blocks and arrows.”
Indeed, it was not worth starting with. We, the developers, are used to writing and reading code, we do it well and love to do it. The code is more compact. In the code we can leave comments. Changes in the code is easier to track in the version control system. You can come up with another 100,500 arguments, probably. But it turns out that WF technology has the following remarkable properties.
First, the algorithm, expressed as a WF scheme, can automatically save and restore its state. This not only frees us from work, but also opens up great opportunities for scaling our application. It is better to show it in the following picture.
At time A on the first computer, the work flow reaches the point where input is required to continue work. Further, state is saved (values ​​of all variables, arguments at the specified point). Then, after some period of time, the required input data is received, and at time B, the state is restored, the algorithm continues to work from the saved point on another computer. It would be great if any C # code had this property, wouldn’t it?
Now it is customary to divide logic into independent sections of code. In particular, and in order to ensure scalability. For example, consider two methods: LogOn and GetData . While it is obvious that the LogOn method is first called, followed by GetData . But when there are many such methods, it can be difficult for us to understand the logic (it can be spread over the entire application) and the order of their implementation. Using WF removes this problem: we have shared tasks that are linked by a thread of the general workflow, displayed as an easy-to-understand flowchart, that even an inexperienced developer can quickly understand the launch rules.
The next completely applied WF feature that you should not have overlooked is the ability to bring program logic to the system configuration area if such flexibility is needed . That is, from the components of the standard .NET Framework delivery, you can assemble a designer as part of your software product. At the system setup stage, the workflows are modified and their properties (for example, launch conditions) are managed. Further, when operating at the required points, it is not the “hard code” that is executed, but the activities created earlier. Thus, WF in combination with Dynamic LINQ is a powerful tool for giving the system such quality as customizability. But, of course, it cannot be said that to configure such a system, no .NET programming skills will be required at all.
It is important that the use of any framework be truly justified. I observe the classic example of the anti-pattern of unjustified use of technology in the current project in an application implemented by the customer on my own. It uses the WF scheme in fact as a replacement for the C # code, which ultimately also degraded greatly due to the lack of knowledge of the technology by all the developers who made the modification. But I must say that the resulting “Frankenstein” slowly, but still performs the duties assigned to it 1 .
Do not use WF without using the above advantages. In this case, we exploit the shortcomings of the technology, despite and perhaps not understanding the merits. This is often the case when studying a new technology, but as many people think, the additional line in the resume is the employer's labor costs for supporting an inappropriate code. But, in fairness, I want to say that in this case the benefits of the knowledge and skills gained will not be very great, as it seems to me.
When a team came to our team to implement a User Store of the type: “As a director, I want the system to apply for leave of employees to be coordinated with the direct manager, then to the personnel department for drawing up an order, and the order, after my signature, left the accounting department for charging vacation pay to eliminate errors and delays, reduce costs, ”it turned out that WF technology is ideal for its implementation. In this case, all the possibilities described above can be used.
In the next section, we will look at a practical illustration of how WF is used in this example.
Source: https://habr.com/ru/post/181562/
All Articles