我继承了一组插件，这些插件似乎是由不同的人开发的。其中一些插件遵循一个主插件的模式，有许多不同的步骤。在这个插件中，没有一个步骤在功能上是内聚的或相关的，作者只是把它们都放在同一个插件中，插件内部的代码（if/else疯狂）处理各种不同的实体、crm消息（更新、创建、删除等）和阶段（预验证/后操作等）。
另一个开发人员似乎为每个实体类型和/或相关的功能分组制作了一个插件。这导致了多个较小的插件，步骤更少。
我的问题是，假设我已经设计出了一种方法来摆脱前一位开发人员在"一个插件来统治所有插件"设计中创建的if/else地狱，那么从CRM性能和长期维护（如减少副作用和部署困难等）的角度来看，哪种方法更可取？
我通常遵循模型驱动的方法，并为每个实体设计一个插件类。在此类中，可以为Create、Update、Delete和其他消息的预验证、操作前和操作后以及异步阶段注册步骤，但每次只能为一个实体注册。
这样做，我可以清楚地监督实体事件触发的插件逻辑，也不需要担心插件步骤的触发顺序。
当然，遵循这种方法意味着我需要一个通用模式来处理所有支持的事件。为此，我设计了一个负责事件路由的插件基类。我的派生插件类只需要实现（覆盖）事件处理程序方法（PreUpdate、PostCreate等）
我认为插件类只能用于将系统事件粘合到业务逻辑。因此，执行所需操作的代码应该放在单独的类中。插件类只路由事件、准备数据和调用业务逻辑。
一些开发人员倾向于每一步甚至每一个实现的需求设计一个插件类。这样做可以使插件类简洁（这是积极的），但当逻辑变得复杂时，您可以很容易地跟踪单个实体的情况。（最近，我使用了一个CRM实现，该实现有一个实体注册了21个插件类。了解发生了什么并向该实体添加新行为被证明是非常棘手和耗时的。）