我继承了一组看似由不同人开发的插件。其中一些遵循一个主插件的模式，具有许多不同的步骤。在这个插件中，没有任何步骤具有内聚性或功能相关性，作者只是将它们全部放在同一个插件中，插件内部的代码（if / else madness）处理各种不同的实体，crm消息（更新，创建，删除等等。）和阶段（preValidation / post operation等）。
其他开发人员似乎为每个实体类型和/或相关功能分组制作插件。这导致多个较小的插件，步骤较少。
我的问题是这个，假设我已经构建了一种方法，以前的开发人员在'one-plugin-to-rule-them-all'设计中创建了if / else地狱，这种方法更适合CRM绩效和长期维护（如减少副作用和部署困难等）的观点？
答案 0 :(得分：2)
我通常遵循模型驱动的方法并为每个实体设计一个插件类。在此类上，可以在创建，更新，删除和其他消息上为预验证，操作前和操作后以及异步阶段注册步骤，但一次只能为一个实体注册。
这样做我可以清楚地监督在实体事件上触发的插件逻辑，而且我也不需要为触发插件步骤的顺序而烦恼。
当然，遵循这种方法意味着我需要一个通用模式来处理所有支持的事件。为此，我设计了一个负责事件路由的插件基类。我的派生类只需要实现（覆盖）事件处理程序方法（PreUpdate，PostCreate等）。
我认为插件类只应用于将系统事件粘贴到业务逻辑中。因此，执行所需操作的代码应放在单独的类中。插件类仅路由事件，准备数据并调用业务逻辑。
一些开发人员倾向于每步设计一个插件类，甚至每个实现的需求。这样做可以使您的插件类简洁（这是积极的），但是当逻辑变得复杂时，您可以很容易地忽略单个实体的运行情况。 （最近我使用了一个CRM实现，其中有一个实体有21个插件类注册它。了解正在发生的事情并向该实体添加新行为被证明是非常棘手和耗时的。）