记录事件的调用顺序 [英] Documenting an event's invocation order

问题描述

在处理特定事件调用的顺序取决于特定事件的执行。例如，使用多情况下代表的缺省后备存储，处理程序将在他们注册的顺序调用。但类设计/实施者可能使用了添加和删除关键字提供事件访问了不同的后备存储，所以调用顺序也不同。

The order in which handlers for a particular event are invoked depends on the implementation of that particular event. For example, using the default backing store of a multi-case delegate, the handlers will be invoked in the order that they were registered. But the class designer/implementer may have used the add and remove keywords to provide an event accessor with a different backing store, and so the invocation order will also be different.

是否有.NET框架基库本身是一个事件的文档precisely描述其调用顺序内的任何情况下？无论是否存在，是否被认为是可接受的做法，依靠这样的记载顺序（例如，用于我执行和记录自己的事件）吗？为什么或者为什么不呢？

Are there any cases within the .NET framework base library itself that an event's documentation precisely describes its invocation order? Whether or not there are, would it be considered acceptable practice to depend on such a documented order (e.g. for an event I implemented and documented myself)? Why or why not?

推荐答案

这是我张贴了这个问题的那天，我的重点是在哪里注册秩序明显和稳定的具体案件。但第二天，我已经注意到，是例外而非规则。

The day that I posted this question, I was focused on a particular case where the registration order was obvious and stable. But the next day I already noticed that to be the exception rather than the rule.

处理程序可以在任何地方进行添加，通过任何code的路径，因此它通常是不可能做任何与该命令非常有用。因此，一般的规则是无视注册秩序，尽量让你的code的工作，不管什么样的顺序处理程序添加/于引用。这有时需要考虑你的工作$ C，即使precautions $ C。在我目前重点的情况下，这需要建立一个伴侣修改事件，配对的更改事件，例如即必须首先发生的事情将进入修改事件的处理程序。

Handlers can be added anywhere, via any code path, so it is normally impossible to do anything useful with that order. As a result, the general rule is to disregard the registration order and try to make your code work no matter what order the handlers are added/invoked in. This sometimes requires taking precautions even after you have working code. In the case I am currently focused on, this required creating a companion Changing event, paired with the Changed event, such that things which must occur first will go into the Changing event's handler.

我想你可以记录一个事件的顺序调用顺序为罕见的情况下，登记是显而易见的，稳定的。但随后对每个登记依赖的顺序，你还需要记录其连续的意义，你不得不记住的您code演变别的东西将打破。听起来像很多工作，所以它可能会更容易只是坚持在前款规定的一般规则！

I suppose you could document an event's sequential invocation order for rare cases where registrations are obvious and stable. But then for each registration that depends on the order, you'd also need to document its sequential significance which you'd have to keep in mind as your code evolves else something will break. Sounds like a lot of work, so it'll probably be easier just to stick to the general rule mentioned in the above paragraph!

我能想到的可靠控制调用顺序的一种潜在可行的办法。你可以通过在优先级处理程序的注册的一部分。这样，你的不可以这取决于在连续报名顺序。但是，您是控制在相对调用顺序。这样的实施是更重的和非标准的，虽然，所以很可能在大多数情况下，不希望的。

I can think of one potentially viable way of reliably controlling invocation order. You could pass in a priority as part of a handler's registration. This way you are not depending on the sequential registration order. But you are controlling the relative invocation order. Such an implementation is heavier and non-standard, though, and so probably not desirable in most cases.

这篇关于记录事件的调用顺序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！