C# 基于事件的vs轮询组件

支持每种设计的考虑因素是什么

假设我正在编写一个输入组件，它收集来自设备（鼠标、游戏板、触摸屏等）的输入

设计它的一种方法是提供一个API，该API包含在给定时间点测试给定状态的方法（此框中是否按下了此按钮？）

另一种方法是让其他组件在每一帧连续调用该组件，检查这些事情，引发事件以通知正在发生的事情（例如，定义一个将由API用户钩住的mouseclick事件）

---

为什么您会喜欢这些设计中的每一种？

最好提供一个API，消费者可以在其中指定一个回调，在事件发生时可以使用相关数据调用该回调。这样，组件的使用者就不会轮询数据。

区别在于“推”模型和“拉”模型之间的区别，如使用代码所示。要么在输入设备的上下文中工作（在某种程度上，操作系统轮询设备以用作事件的触发器，要么只是设置一个在下次轮询之前有效的值）。我认为使用其中一个的决定取决于什么是重要的；它现在被点击了，还是已经被点击了？这种细微的语义差异可能意味着行为上的重大差异

如果您要查找的是在检查时按下按钮，则将其设置为轮询机制。提供一个属性，该属性在库中尽可能频繁地更新，消费者将检查该属性以确定按钮是否被按下

如果您需要传达某个按钮在某个时间被按下，那么将其设置为一个事件，该事件将“推送”该信息给其侦听器

您想使用哪一个取决于您如何构造使用它的程序。在Windows GUI游戏中，程序完全设计为等待输入，最好使用基于事件的模型。一款视频游戏，比如侧滚，你必须知道输入的当前状态才能绘制下一帧，投票机制可能会更好

---

坦率地说，在这样的库中，并排设置这两种场景是很简单的；更新一个属性，然后如果有人在听，大声说出来。通过这种方式，用户可以根据自己的需要推拉代码。

我目前实际上并行实现了部分代码。唯一的问题是，除非定期轮询该组件，否则永远不会引发来自该组件的事件。或者您建议组件本身执行轮询？我建议组件、库等对实际硬件设备或抽象层（即DirectInput）执行轮询，然后设置指示设备状态的属性，这些属性反过来可以通过使用代码进行轮询，然后，当对象的状态发生更改时，也会触发事件。因此，如果我创建一个表示鼠标状态的“Mouse”对象，我会有一个“LeftButtonDown”布尔属性和一个“OnLeftButtonDown”事件，我的消费者可以随意订阅活动或投票。你如何补救那些依赖输入流的侧滚游戏，其中长按按钮被解释为相同输入流，因此，由于响应不是原子的，有延迟响应的感觉，并且在长序列之后按下的新键似乎没有及时被“检测到”…@MywikiWitwiki-这种行为通常是在太高的抽象级别上工作的症状。键盘不会传输其按键产生的字母流；它使用代码系统为每个键提供“向下”/“向上”消息。这种基本的消息传递方式随后被操作系统解释为“他们按了这个键，所以显然他们想要这个字母”，但所有主要的操作系统都保留较低级别的“KeyDown”/“keydup”消息，并且通常感测键的唯一限制是基于硬件的（一些键盘由于布线中的拐角而无法感测某些键组合）。