Questions tagged «event-programming»

事件驱动的编程是指通过识别和处理事件（例如鼠标单击，按键等）来驱动程序流的编程技术。

11
事件监听器如何工作？
在我今天有关Unity的演讲中，我们讨论了通过检查用户是否按下按钮的每一帧来更新播放器位置。有人说这效率低下，我们应该改用事件监听器。 我的问题是，无论使用哪种编程语言或应用哪种情况，事件监听器如何工作？ 我的直觉是假定事件侦听器不断检查事件是否已被触发，这意味着，在我的情况下，与检查事件是否被触发的每个帧没有什么不同。 根据课堂讨论，事件监听器似乎以不同的方式工作。 事件监听器如何工作？
5
什么时候应该使用基于事件的编程？
我一直在传递回调或只是从程序中的其他函数触发函数，以使任务完成后就可以进行操作。完成后，我将直接触发该函数： var ground = 'clean'; function shovelSnow(){ console.log("Cleaning Snow"); ground = 'clean'; } function makeItSnow(){ console.log("It's snowing"); ground = 'snowy'; shovelSnow(); } 但是我已经阅读了许多编程方面的策略，据我了解它强大但尚未实践的策略是基于事件的（我认为我所了解的一种方法称为“ pub-sub”）： var ground = 'clean'; function shovelSnow(){ console.log("Cleaning Snow"); ground = 'clean'; } function makeItSnow(){ console.log("It's snowing"); ground = 'snowy'; $(document).trigger('snow'); } $(document).bind('snow', shovelSnow); 我想了解基于事件的编程的客观优缺点，而不是仅仅从其他函数中调用所有函数。在什么情况下可以使用基于事件的编程？
2
嵌套指令之间的通信
指令之间似乎有很多通信方式。假设您有嵌套指令，内部指令必须将某些内容传递给外部指令（例如，它是由用户选择的）。 <outer> <inner></inner> <inner></inner> </outer> 到目前为止，我有5种方法 require: 家长指令 该inner指令可以要求该outer指令，该指令可以在其控制器上公开某些方法。所以在inner定义中 require: '^outer', link: function(scope, iElement, iAttrs, outerController) { // This can be passed to ng-click in the template $scope.chosen = function() { outerController.chosen(something); } } 在outer指令的控制器中： controller: function($scope) { this.chosen = function(something) { } } $emit 事件 该inner指令可以$emit一个事件，该outer指令可以通过响应，$on。因此，在inner指令的控制器中： controller: function($scope) { …
6
事件循环是否只是具有优化轮询的for / while循环？
我试图了解什么是事件循环。通常的解释是，在事件循环中，您会做一些事情，直到收到事件发生的通知。然后，您可以处理事件并继续做之前的工作。 用示例映射以上定义。我有一台在事件循环中“侦听”的服务器，当检测到套接字连接时，将读取并显示其中的数据，此后服务器将像以前一样继续/开始监听。 但是，此事件正在发生，而我们收到的通知“就像那样”对我来说就很大了。您可以说：“注册事件侦听器不只是那样而已”。但是什么是事件侦听器，但由于某种原因没有返回的函数。它是否在自己的循环中，等待事件发生时得到通知？事件监听器是否还应该注册一个事件监听器？它在哪里结束？ 事件是可以使用的很好的抽象，但是仅仅是一个抽象。我认为，最后不可避免地要进行投票。也许我们没有在代码中执行此操作，但是较低级别（编程语言实现或OS）正在为我们执行此操作。 它基本上可以归结为以下伪代码，这些伪代码在足够低的位置运行，因此不会导致繁忙的等待： while(True): do stuff check if event has happened (poll) do other stuff 这是我对整个想法的理解，我想听听这是否正确。我乐于接受整个想法从根本上是错误的，在这种情况下，我希望有正确的解释。
6
如何在事件驱动的体系结构中处理初始状态？
在事件驱动的体系结构中，每个组件仅在事件通过系统发送时起作用。 假设有一辆带有刹车踏板和刹车灯的假想汽车。 刹车灯在接收到刹车启动事件时亮起，并在接收到刹车关闭事件时熄灭。 制动踏板发送brake_on当它被按下事件和brake_off当它被释放事件。 这是一切都很好，直到你有其中汽车已开启，制动踏板的情况已经按下。由于刹车灯从未收到过刹车事件，因此它将保持熄灭状态-显然是不希望的情况。默认情况下，打开刹车灯只会扭转这种情况。 如何解决此“初始状态问题”？ 编辑：谢谢您的所有答复。我的问题不是关于一辆真正的汽车。在汽车中，他们通过不断发送状态来解决此问题-因此在该域中没有启动问题。在我的软件领域，该解决方案将使用许多不必要的CPU周期。 编辑2：除了@gbjbaanb的答案外，我还将使用以下系统： 假设的制动踏板在初始化后会发送一个事件及其状态，并且 假设的制动灯在初始化后发送一个事件，要求从制动踏板发出状态事件。 使用此解决方案，组件之间没有依赖关系，没有竞争条件，没有消息队列过时，也没有“主”组件。
6
“消息传递”系统与“基于事件”系统的优点
我的问题来自一个没有受过教育的观点。 “ 消息传递 ”系统与“ 基于事件 ”系统的相对优点是什么？ 为什么一个选择另一个？他们的优缺点是什么？ 我不仅想知道“理论上”，而且想知道“实践中”。 编辑： 具体问题： 我想构建可充当小型服务（每个执行一些小任务或提供一些信息）的可插入组件的系统。 服务可以： 分层，以便一项服务的输出可以充当另一项服务的输入之一 具有包含层次结构，因此一个服务可以由另一服务包含，而无需前面句子中提到的特定输入/输出关系 该系统的目标是将另一个系统中的单个低级事件流转换为更高级别的信息和功能，并另外提供一个返回到另一个提供单个事件系列的系统的通道。 如果还不够，我可以提供更多详细信息。 环顾四周后。这和这可能更好地描述我的情况。 看来这很适合我的情况：http : //akka.io/
4
插件应该使用什么：钩子，事件或其他东西？
考虑一个允许插件对其程序流做出反应的应用。 我知道两种方法可以实现：钩子和事件 1.挂钩 在主程序流中使用调用来清空函数。插件可以覆盖这些功能。 例如，Drupal CMS实现了可用于模块和主题的挂钩。这是在file_copy函数中如何实现钩子的示例。 function file_copy(stdClass $source, $destination = NULL, $replace = FILE_EXISTS_RENAME) { // ... [File copying routine] // Inform modules that the file has been copied. module_invoke_all('file_copy', $file, $source); return $file; // ... } 模块可以实现modulename_file_copy($file, $source)将由module_invoke_allin 调用的功能file_copy。该功能完成后，file_copy将恢复执行。 2.活动 拥有应用程序分发事件，插件可以监听该事件。收到已订阅的事件后，插件将拦截程序流并执行必要的操作。 例如，一个jQuery画廊插件Fotorama 实现了几个事件。例如，这show是触发fotorama:show事件的方法的一部分。 that.show = function (options) { …
4
事件驱动的编程：什么时候值得？
好的，我知道这个问题的标题几乎与何时应该使用基于事件的编程相同？但是上述问题的答案并没有帮助我确定我是否应该在遇到的特定情况下使用事件。 我正在开发一个小型应用程序。这是一个简单的应用程序，大部分功能是基本CRUD。 在发生某些事件时（修改某些数据时），应用程序必须在文件中写入所述数据的本地副本。我不确定实现此目标的最佳方法是什么。我可以： 修改数据时触发事件，并将响应（生成文件）绑定到此类事件。或者，实现观察者模式。这似乎是不必要的复杂性。 直接从修改数据的代码中调用文件生成代码。简单得多，但是依赖关系应该是这种方式似乎是错误的，也就是说，将应用程序的核心功能（修改数据的代码）与额外的特权（生成备份文件的代码）耦合起来似乎是错误的。我知道，但是，这个应用程序不会发展到那种耦合带来问题的地步。 在这种情况下最好的方法是什么？
7
如何简化事件驱动代码的维护？
使用基于事件的组件时，在维护阶段我经常会感到有些痛苦。 由于执行的代码都是分散的，因此很难确定在运行时将涉及的所有代码部分。 当有人添加一些新的事件处理程序时，这可能导致难以解决的细微问题。 从评论中进行编辑：即使有一些良好的实践做法，例如具有应用程序范围的事件总线和处理程序将业务委派给应用程序其他部分的处理程序，有时代码也开始变得难以阅读，因为其中有很多来自许多不同地方的注册处理程序（尤其是在有巴士的情况下）。 然后，序列图开始查看复杂的情况，花费时间确定正在发生的事情在增加，调试会话变得混乱（在处理程序上迭代时，处理程序管理器上的断点，尤其是异步处理程序和在其之上进行一些过滤时感到高兴）。 ///////////// 示例 我有一个正在检索服务器上某些数据的服务。在客户端上，我们有一个基本组件，该组件使用回调来调用此服务。为了向组件的用户提供扩展点并避免不同组件之间的耦合，我们触发了一些事件：一个事件在发送查询之前发生，一个事件在返回答案时发生，另一个事件在失败时发生。我们有一组预注册的基本处理程序，它们提供了组件的默认行为。 现在，该组件的用户（我们也是该组件的用户）可以添加一些处理程序以对行为进行一些更改（修改查询，日志，数据分析，数据过滤，数据按摩，UI花式动画，链接多个顺序查询） ， 随你）。因此，某些处理程序必须在其他处理程序之前/之后执行，并且它们是从应用程序中许多不同的入口点注册的。 一段时间后，可能会发生十几个或更多处理程序被注册的情况，并且使用该处理程序可能既乏味又危险。 之所以出现这种设计，是因为使用继承开始变得一团糟。事件系统以一种组合形式使用，您尚不知道组合将是什么。 示例结束 ////////////// 所以我想知道其他人如何处理这种代码。无论是在编写和阅读它。 您是否有任何方法或工具可让您轻松编写和维护此类代码？
1
为什么Protobuf 3将消息上的所有字段都设为可选？
protobuf的语法3使所有字段成为可选字段，从而删除了关键字required以及optional以前的proto2语法。阅读开发人员的一些评论似乎是为了增强向前/向后二进制兼容性而完成的。 但是对我而言，这可以通过仅对软件包名称进行版本控制（例如说）com.example.messages.v1，然后让客户端实施他们理解的反序列化程序来实施。同时，它删除了一些从软件工程的角度来看有用的合同类型。例如，如果我有 message Location { double latitude = 1; double longitude = 2; } 在proto3中，可以Location通过不提供必填字段之一来创建半备份但完全有效的文件。 创建基于模式的序列化格式以在客户端之间交换数据时，这不是一个很大的缺点吗？将额外的验证代码移至每个客户端以检查所有必填字段均具有有效值，这不是更糟吗？
5
是否将事件链接视为良好做法？
我时不时遇到一些场景，在这些场景中，触发事件之前需要满足一些复杂的条件。此外，大多数侦听器还会运行其他检查以确定操作过程。这让我开始思考，更好的解决方案是否是考虑较小的事件并使它们彼此触发。 链接事件将使我以后可以用相当少的精力（可能违反YAGNI？）来编织任何其他侦听器。我的代码将由简单易懂的元素组成，其他人应该不难理解。 但是，此解决方案的可能缺点是，如果链中发生某些错误（例如，由于人为错误导致的错误事件触发），则很难捕获该错误。 被事件链接是个好主意TM？如果不是，那么使事件相关代码变得混乱的替代方法是什么？
2
如何处理事件来源中的副作用？
假设我们要为金融应用程序实现一个小型安全子系统，该子系统将在检测到异常模式时通过电子邮件向用户发出警告。对于此示例，该模式将包括所描述的三个事务。安全子系统可以从队列中读取主系统中的事件。 我想得到的是一个警报，它是系统中发生的事件的直接结果，而没有中间模式来模拟模式的当前状态。 监控已激活 交易已处理 交易已处理 交易已处理 警报已触发（ID：123） 已发送警报电子邮件（ID：123） 交易已处理 考虑到这一点，我认为事件源可以在这里很好地应用，尽管我有一个没有明确答案的问题。在示例中触发的警报具有明显的副作用，需要发送电子邮件，这种情况只能发生一次。因此，在重放聚合的所有事件时不应发生这种情况。 在某种程度上，我看到需要发送的电子邮件类似于查询方生成的实现，这在CQRS / Event采购文献中已经见过很多次了，尽管差别不大。 在此文献中，查询端是由事件处理程序构建的，该事件处理程序可以在给定点生成状态的实现，从而再次读取所有事件。但是，在这种情况下，由于前面解释的原因，不能完全像那样完成。每个状态都是瞬态的想法在这里并不适用。我们需要记录警报发送到某个地方的事实。 对于我来说，一个简单的解决方案是使用其他表或结构，在其中保留先前触发的警报的记录。由于我们具有ID，因此我们可以检查之前是否发布了具有相同ID的警报。拥有此信息将使SendAlertCommand成为幂等。可以发出几个命令，但副作用只会发生一次。 即使考虑到该解决方案，我也不知道这是否暗示此体系结构对此问题有问题。 我的方法正确吗？ 在哪里可以找到更多有关此的信息？ 奇怪的是我还没有找到更多有关此的信息。也许我一直在使用错误的措词。 非常感谢！
1
我应该使用命令还是事件？
在总线通信中，命令和事件之间的区别在我看来似乎有点模糊。我知道命令应该只执行一次，而一个事件可以处理多次，但是我仍然不确定何时使用命令或事件。 让我们看一个例子： 当新用户注册到Web应用程序时，我们应该为他创建一个帐户并发送确认电子邮件。 创建帐户 -这似乎是将a发送CreateUserCommand到总线并由专门的组件处理的正确位置。 也许这甚至不应该使用异步总线通信来实现？我们希望用户能够立即登录到应用程序。对于总线，我们无法保证命令将在何时执行。 发送电子邮件 -组件创建帐户后，我可以看到2种可能性 向总线发送另一个命令 SendConfirmationEmailCommand 发布活动 UserAccountCreatedEvent 而不是让电子邮件发件人组件抓住它并完成任务。 一方面，我希望确认电子邮件仅发送一次（使用命令），另一方面，我相信可能有多个对新注册用户感兴趣的组件。记录器或SMS发送者。 您将如何实施？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.