Workflow Tracking namespace pollution
-
Thursday, October 09, 2008 2:26 PM
There are far too many different types involved in setting up a TrackingProfile.
Why is there a different TrackingPoint class for Workflow, Activity, and User. There's a different class for each of their Locations, these hold the same general type of information, some aspect of Workflow
Just think, instead of this
<?xml version="1.0" encoding="utf-16" standalone="yes"?>
<TrackingProfile xmlns="http://schemas.microsoft.com/winfx/2006/workflow/trackingprofile" version="1.0">
<TrackPoints>
<WorkflowTrackPoint>
<MatchingLocation>
<WorkflowTrackingLocation>
<TrackingWorkflowEvents>
<TrackingWorkflowEvent>Created</TrackingWorkflowEvent>
<TrackingWorkflowEvent>Completed</TrackingWorkflowEvent>
</TrackingWorkflowEvents>
</WorkflowTrackingLocation>
</MatchingLocation>
</WorkflowTrackPoint>
</TrackPoints>
</TrackingProfile>We could have had this:
<?xml version="1.0" encoding="utf-16" standalone="yes"?>
<TrackingProfile xmlns="http://schemas.microsoft.com/winfx/2006/workflow/trackingprofile" version="1.0">
<TrackPoints type="Workflow">
<MatchingLocation type = "WorkflowTracking">
<Events>
<Event>Created</Event>
<Event>Completed</Event>
</Events>
</MatchingLocation>
</TrackPoints>
</TrackingProfile>Now,
TrackPoints can be used for Workflow, Activity, and User
MatchingLocation can be used for Workflow, Activity, and User.
As it is now, the User and Activity TrackPoints have almost identical functionality, but no commn classes.
With a bit more effort I could flatten the entire muddle that is Tracking, and end up with about 1/3 of the classes. and maintain the same functionality. The My code wouldn't be so hard to read, and debug
All Replies
-
Thursday, October 09, 2008 7:30 PM
"Why is there a different TrackingPoint class for Workflow, Activity, and User. There's a different class for each of their Locations, these hold the same general type of information, some aspect of Workflow"
The reason that there are different trackingpoint classes, is that it allows for 3 very different kinds of tracking to be used. From the MSDN page
Workflow events include Created, Completed, Idle, Suspended, Resumed, Persisted, Unloaded, Loaded, Exception, Terminated, Aborted, Changed, and Started. Activity events describe the life cycle of an individual activity instance. Activity-execution status events include Executing, Closed, Compensating, Faulting, and Canceling. When creating the business logic for an activity, the activity author might want to track some business- or workflow-specific data. This can be achieved by calling any of the overloaded Activity.TrackData methods. The data tracked in this manner is sent to the tracking service as a User Tracking Event.
By allowing the user to differentiate between these types in tracking, some users will choose to track only user tracing while others might choose to use all three but log each kind to a sepearte file, etc. Yes, you could flatten that down, and the framework could have as well, but you wouldnt have the same functionality because you would lose some of the control over how they are differentiated.
Info From:
http://msdn.microsoft.com/en-us/library/bb264458(VS.80).aspx -
Friday, October 10, 2008 10:12 AM
Yes, you could flatten that down, and the framework could have as well, but you wouldnt have the same functionality because you would lose some of the control over how they are differentiated.
Sorry, I don't see how one implies the other. My point is that there is no need to have such a vast number of differing types, and that atributes on a flattened type heirarchy would provide the same functoinality without polluting the namespace with so many different types which do essentially the same as other types
example - WorkflowTrackPoint and ActivityTrackPoint are essentially the same thing. They allow you to register a tracking point. Why not just use a single class, and differentiate them by an attribute as in
TrackPoint tp = new TrackPoint( TrackPointType.Workflow ) // (or TrackPointType.Activity)
That's clearly too simple, instead we have twe seperate types
WorkflowTrackPoint, and ActivityTrackPoint
Similarly we have to deal with WorkflowTrackingLocation vs ActivityTrackingLocation
TrackingLocation tl = new TrackingLocation(TrackingLocationType.Workflow); // or Activity
Having seperate types is bad enough, but the naming scheme for the types is chaotic. We add TrackingWorkflowEvent to a WorkflowTrackingLocation, but we add ActivityExecutionStatus to an ActivityTrackingLocation.
Notice that the naming scheme for the two things being added tothe TrackingLocation is completely different, and thus confusing.
Don't get me started on why sometimes it's 'Track' and sometimes 'Tracking' - that's just too much for one day !

