I want to use Windows Workflow to provide a validation service. The validation that will be provided may have multiple tiers with chaining and redirecting to other stages of validation. The application that will generate the data for validation is a Silverlight app.

I imagine the validation will take longer than the blink of an eye, so I don't want to tie the user up. Instead, I would like the user to submit the current data for validation. If the validation happens quickly, the service will perform an asynchronous callback to the app. The viewmodel that made the call would receive the validation output and post into the view.

If the validation takes a long time, the user can move forward in the Silverlight app, disregarding the potential output of the validation. The viewmodel that made the call would be gone. I expect there would be another viewmodel that would contain the current validation output in its model. The validation value would change causing the user to get a notification in smaller notifcation area.

I can see how the current view's viewmodel would call the validation through the viewmodel that is containing the validation output, but I am concerned that the service call will timeout. Also, I think the user may have already changed the values from the original validation, invalidating the feedback.

I am sure asynchronous validation is a problem solved many times over, I am looking to glean from your experience in solving this kind of problem.

Is this the right approach to the problem, or is there a better way to approach this?


1 Answer 1


First of all, I’d like to assume that you are using a WCF service that provides validation services written in Windows Workflow and the Silverlight client use the service to validate some sort of data or initiate a validation operation.

Under this scenario, you have to separate long running and short running validation operations and provide a different UI framework for each of them. Short running validation should be handled with the usual asynchronous request-reply model used by Silverlight, which means that the user will wait (without blocking) for the result of validation. This is the ordinary flow of most Silverlight applications. Long running validation should be handled in a different way. You can’t use force the user to wait for a result. It’s probably better to use a “notification mechanism” to notify user asynchronously with the results of validation and provide a way to “edit” or “resubmit” the operation in case the validation return an error or failure.

In other words, Windows Workflow is just a way to “glue” the validation steps. You should handle the design and implementation of the rest.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.