何时在自定义模块中调度事件？

这是关于Magento 1和Magento 2的问题。

我了解，作为一种好的做法，鼓励第三方模块开发人员在其自定义模块中调度事件，以使其更易于与其他模块一起使用。

我想知道：

• 开发人员应在哪里在自定义模块中调度事件？
• 有没有建议的地点来安排活动？例如，控制器，模型，块，助手，观察者？
• 调度事件如何影响性能？

您不会在这里找到一个好的，明确的，确定性的答案。总的来说，您应该在模块中将事件分派到您和您的用户需要的地方，如果您无法想到可能需要的事件，则不需要分派它们。Magento本身在许多不同的地方发出了如此多的事件（控制器前/后分派，任何crud操作等），以至于您的模块无需进行任何操作就已经可以分派许多有用的事件。

由于这并不令人满意，因此您希望模块在模块采取某些措施（用户可能希望向其中添加项目，从中删除项目，更改或采取独立于原始操作的措施）时调度事件。例如-Magento的visitor_init事件不属于其标准的自动生成事件套件。此事件允许程序员在Magento记录数据之前修改访问对象。这些是原始模块开发人员无法确定地了解的方式这是需要添加事件的地方-它可能来自功能请求和/或对系统用户的采访。知道您的用户想要什么，如果无法/不可行地构建UI / UX以使其通过admin进行操作，请添加一个事件挂钩，以便其他程序员可以为他们执行此操作。

不那么性感的是，添加事件也是使开发人员（您的用户，甚至您的团队）能够将一些功能添加到每个人都不敢触摸的粗糙代码中的一种廉价方法。将您的dispatchEvent调用放在代码的中间，并挂接到它，您就可以添加功能而不会在原始范围内干扰代码。[编辑：同样，您应该在某个时候重构糟糕的代码]

在性能方面，将事件添加到调度将取决于您添加事件的位置。调用dispatch事件时，Magento需要进行一些额外的PHP调用，为任何已配置的观察者查询配置，然后调用观察者。完成一次后，这是标准Magento调度范围内的廉价添加。但是，反复进行（例如，在渲染每个块之前），这可能会加起来。这里没有良好的经验法则-因为正确的答案总是个人资料。

最后，w / r / t Magento 2，现在说还为时过早。以上所有内容仍然适用-但是插件系统增加了一些皱纹。从某种角度来看，插件是一种为Magento中的任何公共方法调用创建类似行为的事件的方法。从理论上讲，如果您正确地设计类，则永远不需要事件。但是，在实践中，如果替代方法是一个漫长的重构过程，那么将事件放入一些受保护的方法或私有方法代码中将是Magento开发人员的诱人解决方案。同样，创建一个专门命名的事件通常可以为使用您的模块的开发人员创造更友好的体验。

希望有帮助！

对于Magento 1，在所有CRUD操作之前和之后以及渲染之前和之后，抛出事件的好时机。核心中的抽象类已经提供了许多此类功能，因此实际上不需要很多第三方事件。

使用Magento 2的情况有所不同。由于可以使用插件拦截公共方法调用，因此不再需要自定义事件。
在设计类时，与其简单地将每个方法都公开以使其可以被拦截，不如将一个大类分解为多个较小的类。
然后，每个较小的类都可能具有一个或两个命名合理且可拦截的公共方法。

就像Vinai所说的，在CRUD操作之前/之后。调度事件的另一个重要位置是adminhtml表单块（如果适用）。这样，如果您添加了自定义属性/字段，则无需添加管理表单块即可添加新的输入字段。（这是针对Magento 1的）。看例子

在Magento 1内部，您可以通过发生的自动触发事件来利用事件。您需要做的就是在模型上设置$_eventPrefix和$_eventObject属性。另外，您还可以通过控制器上的'controller_action_predispatch_ ' . $this->getFullActionName()和'controller_action_postdispatch_' . $this->getFullActionName()事件自定义触发控制器事件。这些可以带您到达那里的大部分地方。

对于Magento 2，请将您的方法在类内公开。这允许插件拦截您的方法。如果您遵循此步骤，则不必创建任何自定义事件。

我希望这有帮助！