c# - 计时器、UI 框架和不良耦合——有什么想法吗？

Question

我刚刚编写了一个小型的 XBox 360 无线 Controller 托管界面，基本上环绕低杠杆 SlimDX包装器库，并为 XBOX 360 Controller 提供简单的托管 API。

在内部，该类每 N 毫秒轮询一次游戏 handle ，并在检测到 Controller 基础状态发生变化时触发事件。

我正在经历一些计时器的死胡同，它基本上迫使我们在两害相权取其轻之间做出选择:

• 要么使我的 XBox360GamePad 类 UI 框架特定(即支持 WPF/WinForms 将在类中硬编码，并且类必须引用这些框架...)

• 使类完全与框架无关，但强制用户使用 Dispatcher.Invoke/Invoke() 调用散布他们的代码，以便能够根据生成的事件更新 UI。

如果我选择后一个选项(使代码 UI 不可知)，那么我基本上使用“通用”System.Timers.Timer 或任何不依赖 UI 的计时器。在那种情况下，我最终会从无法直接更新 UI 的线程生成/调用事件，即在 WPF 中，我将不得不通过(丑陋的)使用 Dispatcher.Invoke 发出来自 360 Controller 类的每个更新.

另一方面，如果我在 XBox 360 Controller 类中使用 DispatcherTimer，我有一个可以直接更新 UI 的工作组件，没有大惊小怪，但现在我的整个 Controller 类都耦合到 WPF，它不能在不依赖 WPF 的情况下使用(即在纯控制台应用程序中)

我正在寻找的是某种解决方案，它使我既可以与框架无关，也可以更新 UI，而不必求助于各种 Dispatcher.Invoke() 技术...例如，如果所有计时器都有一个共享基类，我可以根据相关场景以某种方式将计时器作为依赖项注入(inject)。有没有人成功处理过这类问题？

Answer 1

轮询架构是唯一的选择吗？

无论如何，我个人会重组系统，以便外部世界可以订阅从 Controller 类触发的事件。

如果您希望 Controller 在正确的线程上下文中触发事件，那么我会为 ISynchronizeInvoke 接口(interface)添加一个属性，如果该属性在 Controller 内部为非空，则使用该接口(interface)，否则只调用事件直接在 Controller 运行的线程上。

例如，这将允许您将整个轮询事情变成一个线程，每 N 毫秒唤醒一次以完成其工作，或者甚至使用事件对象来等待事件(如果 360 Controller 架构有类似的东西)。