Customer experience | Sales, Customer Insights,...

Is there a Plugin Design Convention ?

(0) Share

Report

Posted on by ErickTreeTops

So I have my first plugin working (yeah me).

I've included both the "Create" and "Update" logic for an Entity in the same class.

This got me thinking. How to design a plugin.

Should you only create one plugin per entity and use code in the execute method to determine if the call is a PreValidation or Postvalidation and then test for the message type "Create", "update" etc.

Then branch off to methods\ non plugin classes that cater for each combination of options.

Here you know where the first call will be for every occurrence.

Or, should you breakdown the plugins for each entity into Post and pre validation and then the message type. eg.

PersonPreCreate.cs PersonPreUpdate.cs

is there a best practice ?

The answer , "it depends on the situation" could be true.

But for large organisations with multiple developer groups, commonality of design would help with learning curves, so would take preference over individual style.

All responses (4)

Answers (0)

Michel Gueli 982 on at

Like (0)

Report

RE: Is there a Plugin Design Convention ?

This is not true. It depends on where you put your logic. My logic is always outside of the plugin classes. That makes it reusable.
Michel Gueli 982 on at

Like (0)

Report

RE: Is there a Plugin Design Convention ?

Some Tips:

-Seperate plugin logic from the actual plugin classes, which implement IPLUGIN. Much easier to test.

-I have a plugin class for each step I use. Folder for each entity. Example incident Folder.

--PreOperationIncidentCreate.cs

--PostOperationIncidentCreate.cs

--PreOperationIncidentUpdate.cs

--PostOperationIncidentClose

-Update same entity where plugin is running on? Yes --> ? PreOperation, No --> PostOperation

-Custom Security checks --> PreOperation
Suggested answer

Bipin D365 28,964 Super User 2024 Season 1 on at

Like (0)

Report

RE: Is there a Plugin Design Convention ?

Hi,

If you would like to know the best practices to be followed when designing the plugin then please have a look at below docs page -

docs.microsoft.com/.../

Now coming to your question on number of classes for plugin-

It depends on the requirement, ideally we should have one plugin class per file and then check appropriate message and stage in your code to execute your business logic. However there are some exceptions where you will have to create multiple class file. For instance on same the stage you want to have multple logic to be executed in an order.

Execution Order -1 Execute some code on Post Update,

Execution Order - 2 Execute some code on Post update,

In this case you will need to create two separate plugin class.

Please mark my answer verified if this is helpful!

Regards,

Bipin Kumar

Follow my Blog: xrmdynamicscrm.wordpress.com/
Suggested answer

Guido Preite 54,087 Super User 2024 Season 1 on at

Like (0)

Report

RE: Is there a Plugin Design Convention ?

as you wrote: "it depends on the situation"