Dynamics crm 2011 CRM 2011插件开发最佳实践

我继承了一组似乎由不同的人开发的插件。其中一些插件遵循一个主插件的模式，包含许多不同的步骤。在这个插件中，没有一个步骤在功能上是内聚的或相关的，作者只是简单地将它们放在同一个插件中，插件内部有代码（if/else-madness），用于处理各种不同的实体、crm消息（更新、创建、删除等）和阶段（预验证/后期操作等）

另一个开发人员似乎为每个实体类型和/或相关功能分组制作了一个插件。这会产生多个更小的插件，步骤更少

---

我的问题是，假设我已经设计出一种方法，摆脱了前一位开发人员在“一个插件来管理所有插件”设计中创建的if/else地狱，那么从CRM性能和长期维护来看，哪种方法更可取（例如，副作用和部署困难更少等等）透视图？

我通常采用模型驱动的方法，为每个实体设计一个插件类。在这个类中，可以为创建、更新、删除和其他消息的预验证、预操作和后操作以及异步阶段注册步骤，但每次只能注册一个实体

这样做，我可以对实体事件触发的插件逻辑保持清晰的监督，而且我不需要担心插件步骤触发的顺序

当然，遵循这种方法意味着我需要一个通用模式来处理所有支持的事件。为此，我设计了一个插件基类来负责事件路由。我的派生插件类只需要实现（覆盖）事件处理程序方法（PreUpdate、PostCreate等）

依我看，插件类应该只用于将系统事件粘附到业务逻辑上。因此，执行所需操作的代码应该放在单独的类中。插件类只路由事件、准备数据和调用业务逻辑

---

一些开发人员倾向于为每个步骤甚至每个实现的需求设计一个插件类。这样做可以使你的插件类简洁（这是积极的），但当逻辑变得复杂时，你可以很容易地失去对单个实体的跟踪。（最近我使用了一个CRM实现，其中有一个实体注册了21个插件类。了解正在发生的事情并向该实体添加新行为被证明是非常棘手和耗时的。）

问题不大：您已经命名了一个插件的每一个缺点来管理它们。根据我的经验，对管道阶段、步骤属性和后期/前期图像的细粒度控制可以产生更好的可维护性和性能。因为这种控制级别是在配置插件步骤时完成的，所以使用一个插件来管理它们不会失去任何可配置性。正如我提到的，我已经找到了一种从架构上移除if/else地狱的方法，所以即使这样也不是问题。我的问题主要是最后一句话。在一个插件中处理所有内容是否会产生新插件开发人员可能不知道的后果。CRM中的处理和实体交互可能非常复杂，我正在寻找是否应该花时间分解大插件的反馈，或者是否应该将较小的插件合并到较大的插件中。如果这“不是什么问题”，那么就让其他人来处理。谢谢，这个概述非常有用。由于不是CRM开发人员并且继承了一个项目，因此很难判断如何最好地重构（或不重构）现有代码，以使将来的扩展和维护易于管理。我相当肯定，execute方法中的混合实体、复制粘贴、800多行不是一个好方法。我经常使用类似的方法，将插件保留在一个程序集中，但有时最好将它们拆分为不同的类和/或程序集