Plug – In Coding Standards – simplifying your xRM code when you implement for a Customer

xRM ISVs would do the opposite of what is described here. 

Coding

Assume Plug–In, customizations etc … have been correctly configured:

• No need to check for infinite loop detection
• No need to use dynamic entities
• No need to check against the right entity
• Assume entity is correctly configured
• Assume custom attributes have been correctly configured

This will:

• reduce lines of code
• make code easier to read [less indents]
• ‘optimised’ – cut out unnecessary checks

By default throw InvalidPluginExecutionException.

Configuration

By default set Plug-Ins to Asynchronous Pre-stage.

• Asynchronous Plug – Ins can be faster to execute since they move to a queue.
• An infinite loop is less likely to occur with a Pre – Stage plug – in since you don’t need to call an Update generally.

 

Naming

• No need to prefix Plug-In in .cs file name
• No need to prefix Plug-In in Class name
• No need to prefix Plug-In in Namespace
• No need to prefix Plug-In in Solution name
• No need to prefix tenancy in .cs file name
• No need to prefix tenancy in Class name
• No need to prefix tenancy in Namespace
• No need to prefix tenancy in Solution name

Similar – no need to use Hungarian notation – look at declaration - class is inherited from Plug-In

Tenancy Management – can read it from Security Key – not necessary to prefix each class within a tenancy

 

Grouping Projects

• Use Separate Solutions for un-related plug-ins, put each project in a separate solution if needed – will make it easier to isolate bugs
• Use Separate Namespaces for un-related Classes.