I am currently using WF to develop the processing workflow for my application. Each activity either is or leverages my CSLA BO's to perform the requisite steps but I need to also drive my UI so that the right information is displayed and/or prompted for based on the workflow. Any ideas?
I am using WF because the workflow is customizable either by directly changing the XAML code or through a series of settings and configuration options that are used by the workflow process. We need a highly dynamic engine and WF works perfectly.
The problem is that I have to support several UI technologies, so it is critical that the UI remains decoupled from the business logic (workflow). My design calls for the business logic to be accessed through a service interface that will allow multiple UI clients to connect and follow the same logic, flow, etc. But I am at a loss for the right technique to drive the UI clients.
Most examples, and frankly my own mind, sees navigation as the responsibility of the UI. In my case, I need some way of telling the UI what page/screen/window to show in response to a change in the workflow.
As an example, think of a simple wizard-style interface. My UI needs to call my service and ask what to show first, then pass the user's input back to the service and have the service tell it what to display next based on the user's input, workflow, configuration and settings.
Any suggestions?
It seems to me that the workflow can't directly drive the UI, because then it would need to know too much about the UI.
Instead what you need is an abstraction layer that sits between the UI and the workflow. So the workflow can alter some object or state value to indicate which logical screen should be shown next, and your UI abstraction layer can map that to a concrete screen appropriate for the particular UI type, and can navigate the user to that screen.
Logically you might say that the user needs to see the "select customer" screen. Physically that might be a web page, or a WPF form. So the actual screen object type is very different, and the process of navigating to or displaying that form would be different.
So you'd need a "UI manager" for the web, and a different one for WPF - but they could both drive off the fact that the workflow wants them to move to the logical "select customer" screen.
Copyright (c) Marimer LLC