How do I design a Wizard-based system with SoC in mind?

Question

I'm building a Windows Forms system (in C# if it matters to anyone) that provides an application automation service. As this application is targeted at users who are not computer savvy, I've decided to simplify things for the user with a wizard UI. I'd like to avoid coupling the views and view engine (from which the Wizard will be built) to the automation engine.

The problem I'm having is that the automation engine, which runs on a separate thread while it does its thing, needs to report status information back to the user, as well as listen for cancel or pause events from the user. Since I don't want the view engine or the automation engine to rely on each other, I'm having a hard time figuring out how to provide for this information conduit.

Any insights into this issue I'm having would be greatly appreciated. I've been wracking my brain for a couple weeks now on this point, and I really don't want to give up and just couple everything together.

If anyone needs additional details to help come up with some sort of idea please let me know and I'll be happy to provide them.

Answer 1

Why not have a thread safe object in the middle that serves as a communication platform between the two? This class would have events of its own as well as properties and methods that provide ways to input and extract needed information. You could even take this a step further and if you have multiple wizards and automation platforms running at the same time if they are uniquely identifiable I would set up a hash of wizard id to platform id and your object could handle communications for multiple pairs at a time. This would require being very careful that everything is thread safe and that the communication you are performing is only using information that is relevant to that wizard-platform pair.

I know this is a broad answer, but I would look at this approach before any other. It gives you the desired separation of concerns and also serves to provide you a communication platform that can be as versatile as you design it to be.

Finally, a word of advice, which you probably don't need. You should not make the communication class dependent on anything that could possibly cause you to run into a circular reference issue. I would make the class as agnostic as reasonably possible, any objects that it requires should be separate from the objects that the wizard/platform requires, unless those are rather generic in nature, so that you have true separation of concerns.

Hope this helps.