CRM 2011 插件开发最佳实践
CRM 2011 Plugin development best practice
我继承了一组看起来是由不同人开发的插件。其中一些遵循具有许多不同步骤的一个主插件的模式。在这个插件中 none 的步骤是内聚的或在功能上相关的，作者只是将它们全部放在同一个插件中，插件内部代码（if/else 疯狂）处理各种不同的实体，crm消息（更新、创建、删除等）和阶段（preValidation/post 操作等）。
其他开发人员似乎为每个实体类型 and/or 相关功能分组制作了一个插件。这导致多个更小的插件具有更少的步骤。
我的问题是，假设我已经设计了一种方法来摆脱先前开发人员在 'one-plugin-to-rule-them-all' 设计中创建的 if/else 地狱，从 CRM 性能和长期来看，哪种方法更可取维护（如较少的副作用和部署困难等）观点？
我通常遵循 模型驱动方法 并为每个实体设计一个插件 class。在此 class 上，可以为创建、更新、删除和其他消息上的预验证、预操作和 post 操作以及异步阶段注册步骤，但每次始终只针对一个实体.
这样做我可以清楚地监督在实体事件上触发的插件逻辑，而且我不需要担心插件步骤的触发顺序。
采用这种方法当然意味着我需要一个通用模式来处理所有支持的事件。为此我设计了一个插件库 class 负责事件路由。我的派生插件 classes 只需要实现（覆盖）事件处理程序方法（PreUpdate、PostCreate 等）。
我认为插件 classes 应该只用于 glue 系统事件到业务逻辑。因此，执行所需操作的代码应放在单独的 class 中。插件 classes 仅路由事件、准备数据和调用业务逻辑。
一些开发人员倾向于为每个步骤甚至每个实现的要求设计一个插件 class。这样做可以使您的插件 class 简洁（这是积极的），但是当逻辑变得复杂时，您可以轻松地跟踪单个实体正在发生的事情。 （最近我使用了一个 CRM 实现，它有一个注册了 21 个插件 classes 的实体。了解正在发生的事情并向该实体添加新行为被证明是非常棘手和耗时的。）
我继承了一组看起来是由不同人开发的插件。其中一些遵循具有许多不同步骤的一个主插件的模式。在这个插件中 none 的步骤是内聚的或在功能上相关的，作者只是将它们全部放在同一个插件中，插件内部代码（if/else 疯狂）处理各种不同的实体，crm消息（更新、创建、删除等）和阶段（preValidation/post 操作等）。
其他开发人员似乎为每个实体类型 and/or 相关功能分组制作了一个插件。这导致多个更小的插件具有更少的步骤。
我的问题是，假设我已经设计了一种方法来摆脱先前开发人员在 'one-plugin-to-rule-them-all' 设计中创建的 if/else 地狱，从 CRM 性能和长期来看，哪种方法更可取维护（如较少的副作用和部署困难等）观点？
我通常遵循 模型驱动方法 并为每个实体设计一个插件 class。在此 class 上，可以为创建、更新、删除和其他消息上的预验证、预操作和 post 操作以及异步阶段注册步骤，但每次始终只针对一个实体.
这样做我可以清楚地监督在实体事件上触发的插件逻辑，而且我不需要担心插件步骤的触发顺序。
采用这种方法当然意味着我需要一个通用模式来处理所有支持的事件。为此我设计了一个插件库 class 负责事件路由。我的派生插件 classes 只需要实现（覆盖）事件处理程序方法（PreUpdate、PostCreate 等）。
我认为插件 classes 应该只用于 glue 系统事件到业务逻辑。因此，执行所需操作的代码应放在单独的 class 中。插件 classes 仅路由事件、准备数据和调用业务逻辑。
一些开发人员倾向于为每个步骤甚至每个实现的要求设计一个插件 class。这样做可以使您的插件 class 简洁（这是积极的），但是当逻辑变得复杂时，您可以轻松地跟踪单个实体正在发生的事情。 （最近我使用了一个 CRM 实现，它有一个注册了 21 个插件 classes 的实体。了解正在发生的事情并向该实体添加新行为被证明是非常棘手和耗时的。）