如何设计一个考虑到 SoC 的基于向导的系统？
我正在构建一个提供应用程序自动化服务的 Windows 窗体系统（如果对任何人都重要的话，则使用 C# 语言）。由于此应用程序针对的是不懂计算机的用户，因此我决定使用向导 UI 来为用户简化操作。我想避免将视图和视图引擎（从中构建向导）耦合到自动化引擎。
我遇到的问题是，自动化引擎在执行其任务时在单独的线程上运行，需要向用户报告状态信息，并侦听来自用户的取消或暂停事件。由于我不希望视图引擎或自动化引擎相互依赖，因此我很难弄清楚如何提供此信息管道。
对于我遇到的这个问题的任何见解将不胜感激。在这一点上我已经绞尽脑汁了几个星期，我真的不想放弃，只是将所有事情结合在一起。
如果有人需要更多详细信息来帮助提出某种想法，请告诉我，我很乐意提供。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为什么不在中间有一个线程安全对象作为两者之间的通信平台呢？此类将具有自己的事件以及提供输入和提取所需信息的方法的属性和方法。您甚至可以更进一步，如果您同时运行多个向导和自动化平台（如果它们是唯一可识别的），我将设置向导 id 到平台 id 的散列，并且您的对象可以处理多个对的通信时间。这需要非常小心，确保一切都是线程安全的，并且您正在执行的通信仅使用与该向导平台对相关的信息。
我知道这是一个广泛的答案，但我会先考虑这种方法。它为您提供了所需的关注点分离，并且还为您提供了一个可以像您设计的那样多功能的通信平台。
最后，一句建议，你可能不需要。您不应该使通信类依赖于任何可能导致您遇到循环引用问题的内容。我将使该类尽可能地不可知，它所需的任何对象都应与向导/平台所需的对象分开，除非这些对象本质上相当通用，以便您真正实现关注点分离。
希望这有帮助。
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.