State machine WF Quandary
I'm chomping at the bit to implement WF, but in need of a few high level pointer when it comes to design.
I intend to implementing a State machine WF into a typical n-tiered asp.net app.
I have a "Supplier" object that can have various states. As a
Supplier's state changes, Email notifications are sent. Pretty simple.
The catch is that the make up (body, subject, etc) of the email itself is driven by; the state of the Supplier object; who set the state change; and other db related data.
My quandary is this: the WF could :
a)handle the email activity if it were passed enough info to carry out the activity.
b)or it could try to connect to the database directly to find out.
In a) it seem a bit pointless as by giving all the info to WF I could just have easily done the job in the business objects.
In b) I have recursive reference problem were the UI references the WF and the BO layer - so the WF can't ref the BO layer (because it is itself ref by the UI).
I can the vision of decoupling processes and reusing processes across systems - but I'm having trouble coming up with a solution as to how to implement this vision inside a typical n-tier data driven asp.net app.
Appreciate any pointers ...
Cheers,
John,
MCAD.NET
Perth,
Western Australia
