TempHire and Cancellation Tokens

You might be too optimistic with your understanding of the cancellation token. The cancellation token is only a request to cancel an operation. There's no guarantee that the request is processed in time or processed at all. For example in DevForce, once a query is sent to the server it can no longer be cancelled. In addition if you let the user proceed before all the data is loaded you risk older queries overwriting the results of newer queries, because there is no guarantee that the results arrive in the same sequence as the queries were executed. What this means is that your UI has to be prepared to receive results out of sequence and results that are no longer needed. Both cases can be dealt with by using sequence numbers to correlate the results to the original queries and decide whether the results should be discarded. Using a cancellation token to attempt to cancel the queries will buy you very little. You still have to deal with out of sequence results and results that were sent to the client because the cancellation request came in too late.

 

These concerns are not there in the latest version of TempHire, because it doesn't reuse ViewModels when the user changes the root entity, so there is no risk of out of sequence results. As you've probably noticed, TempHire doesn't prevent the user from selecting another staffing resource while the previous one is still loading, but because it loads each staffing resource into a new detail composition, it doesn't have to deal with the above.