我繼承了一組看似由不同人開發的插件。它們中的一些遵循一個主插件的模式，具有許多不同的步驟。在這個插件中，沒有一個步驟在功能上是內聚的或相關的，作者只是將它們全部放在同一個插件中，插件的內部代碼（if/else madness）處理各種不同的實體，crm消息（更新，創建，刪除等）和階段（預驗證/後期操作等）。CRM 2011插件開發最佳實踐
其他開發人員似乎爲每個實體類型和/或相關功能分組製作插件。這導致多個更小的插件和更少的步驟。
我的問題是這樣的，假設我已經構建了一個出路，以前的開發人員在'one-plugin-to-rule-them-all'設計中創建了if/else地獄，哪種方法更適合從CRM績效和長期維護（如更少的副作用和部署困難等）視角？
我通常遵循模型驅動的方法併爲每個實體設計一個插件類。在此類上，可以在創建，更新，刪除和其他消息中註冊預驗證，預操作和後操作以及異步階段，但一次只能爲一個實體註冊。
這樣做，我可以保持對實體事件觸發的插件邏輯的明確監督，也不需要擔心插件步驟的觸發順序。
按照這種方法，當然，意味着我需要一個通用模式來處理所有支持的事件。爲此，我設計了一個負責事件路由的插件基類。我派生的插件類只需要實現（覆蓋）事件處理程序方法（PreUpdate，PostCreate等）。
林我的意見插件類應該只用於膠系統事件的業務邏輯。因此，執行所需操作的代碼應放置在不同的類中。插件類僅路由事件，準備數據並調用業務邏輯。
一些開發人員傾向於每步設計一個插件類，甚至每個實現的需求。這樣做可以保持插件類的簡潔（這是正面的），但是當邏輯變得複雜時，您可以輕鬆地跟蹤單個實體正在發生的事情。 （最近我使用了一個CRM實現，這個實現有一個實體有21個插件類註冊了，瞭解正在發生的事情並向這個實體添加新的行爲被證明是非常棘手和耗時的。）
謝謝，這個概述非常有幫助。不是一個CRM開發者並且繼承一個項目使得很難判斷如何最好地重構（或不重構）現有的代碼以使未來的擴展和維護易於管理。我相當肯定，混合實體，複製粘貼，800多行的執行方法並不是一個好方法。 – Bitfiddler
我經常使用類似的方法並將插件保留在一個程序集中，但有時候最好將它們拆分爲不同的類和/或程序集 –
沒有太多的問題：你已經命名爲one-plugin-rule-them-all的每一個缺點。根據我的經驗，對Pipeline Stage，Step Attributes和Post/Pre-Images的細粒度控制可提供更好的可維護性和性能。 – Filburt
由於該級別的控制是在配置插件步驟時完成的，因此您不會因爲one-plugin而失去任何可配置性來統一它們。 – Bitfiddler
正如我所提到的，我已經想出了一種方法來架構刪除if/else地獄，所以即使這不是問題。我的問題主要是最後一句話。是否在一個插件中處理了所有內容會產生新插件開發人員可能不知道的任何後果。 CRM中的處理和實體交互可能非常複雜，我正在尋求反饋意見，看我是否應該花時間分解大插件，或者是否應該將較小的插件合併爲較大的插件。如果這不是一個問題，那麼讓其他人來處理它。 – Bitfiddler