Windows WorkFlow 4.0
I'm currently reading up on WorkFlow 4.0 for a project I'm are working on. I'm wondering if there is any precedence for best practices. A few quick searches on Google pull up a few good links in MSDN such as these two:
http://msdn.microsoft.com/en-us/library/cc597937.aspx
http://msdn.microsoft.com/en-us/magazine/dd252947.aspx
They both seem somewhat relevant and mostly helpful. Still I was looking more for something more in depth on things like some thoughts on 'how many layers down in an activity before you need to start encapsulating it into a new activity class', similar to best practices for other OOP and SOA design.
So far I haven't found much, but then again, it is still such a young and under-used technology. My recommendation so far is basically to apply whatever principles of OOP that can fit. For example: One activity class should do one job and one job only, but may call any number of other activities to accomplish that job. In some ways, WF magnifies the annoyance of having a single method doing too many things because those other things will likely be masked into some sub activity, if block, flowchart, sequence, etc, that you have to actually double click into just to see what it is doing. A nasty 100 line method might be hopelessly layered in WF unless it were sufficiently decomposed into properly named activities.
On that particular example, it would be nice if a tooltip would show you the basic content of an activity if you hovered over it.
http://msdn.microsoft.com/en-us/library/cc597937.aspx
http://msdn.microsoft.com/en-us/magazine/dd252947.aspx
They both seem somewhat relevant and mostly helpful. Still I was looking more for something more in depth on things like some thoughts on 'how many layers down in an activity before you need to start encapsulating it into a new activity class', similar to best practices for other OOP and SOA design.
So far I haven't found much, but then again, it is still such a young and under-used technology. My recommendation so far is basically to apply whatever principles of OOP that can fit. For example: One activity class should do one job and one job only, but may call any number of other activities to accomplish that job. In some ways, WF magnifies the annoyance of having a single method doing too many things because those other things will likely be masked into some sub activity, if block, flowchart, sequence, etc, that you have to actually double click into just to see what it is doing. A nasty 100 line method might be hopelessly layered in WF unless it were sufficiently decomposed into properly named activities.
On that particular example, it would be nice if a tooltip would show you the basic content of an activity if you hovered over it.
