Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
I have seen lots of CRM code and my initial thoughts are CRM developers don’t seem to create many classes or spend much time designing their code. In this blog post I will discuss the effects of not creating classes and explain the benefits of classes and abstractions.
The problem seems to be self reinforcing. Previous CRM projects contain few classes and most of the code exists in the plugin, this sets an unspoken standard which encourages developers to not create classes.
This is a mixture of a safety in numbers/wisdom of crowds approach, it could be seen as consistency and a standard approach to CRM development is good. Consistency in CRM development helps developers maintain, debug and extend CRM projects.
In the case of putting code in the plugin and not creating classes I think it’s bad practise and every plugin you add creates more technical debt for the CRM project and CRM projects quickly resemble legacy projects with complex CRM customizations
The end result is complex code doing lots of things and impossible to reuse and extremely difficult to work with (maintain, debug, read, etc).
To not use classes and put all or the bulk of the code in the plugin class
CRM plugins are often small, focused code but to not create classes or abstractions is to create a code base technical debt. This debt is paid back when CRM developers take longer to interact with the code in the future.
Plugins with few or no classes results in each developer creating new code every time because it’s impossible to reuse any of the code in the other plugins.
If CRM developers are not creating classes they are creating legacy code and plugins contain monster methods – Hosk
The focus when creating code should be to keep the quality high, test everything and keep code as simple as possible.
When you create plugins or every time you make a code change you make you should leave the code in better state than you found it. Why you should write code and customizations like a boy scout
Quality of code is fundamental to the long term success of a CRM project and as soon as you lower your coding standards and let in bad code, it will soon spread Bad code is like a virus, don’t get infected
I advocate no code logic should be added to the plugin class except a call to a class passing in the entity, IOrganisationService, ITracing.
Putting logic in a plugin creates complex code, which is difficult to unit test but there are other reasons to create classes which are listed below
Duplicate code is one of the worst code smells and it has multiple bad side effects
When ever you find duplicate code or are about to create duplicate code, take the opportunity to find the common behaviour and abstract it into a class. This will enable you to reuse this single piece of code in many places.
Using classes and functions is the primary weapon against duplicate code because you are logically sorting code in logical class/method, which will allow developers to easily find and use it.
Classes allow you to model real world objects (account) and abstract concepts (printing, validating). The benefit is you can split up the code into logical abstractions which give clarity to the intent of the code.
CRM out of the box models plenty of real world objects
You can create classes to model behaviours, this could be things like validating, printing, logging. These behaviours can be use in composition and used in multiple classes. The benefit of modelling behaviours is reuse
Classes reduce complexity by splitting code into abstract or logical sections. The term abstract can be confusing, instead replace it with logical groups. Splitting code into logical groups organises the code into smaller/reusable sections.
Breaking the code into classes creates cohesive code and reducing dependencies between classes.
Creating well named classes with well named methods reduces complexity and makes the code using those methods and classes easier to read/understand.
Creating classes and methods allows you to create descriptive methods, e.g. call the a print method is easier to understand than reading all the lines of code needed to print. At a high level you might not need to know all the details of printing.
Classes help reduce the effects of change by removing dependencies between classes (assuming the classes are well designed). Using abstract classes can remove the effects of change on the code using the abstract classes.
Well designed code can make it easy to add new types by encapsulating what varies and programming to interfaces. Adding a new type should not effect the other types or the code using the abstract class.
Managing the effects of change can reduce dependences and stop changes in code unexpectedly breaking other parts of the system. You could rename this to limiting the effects of change by reducing the ripple effect change has on badly designed code.
Read my blog post Good coding practices – Information hiding
You can structure classes to hold the data instead of passing lots of variables between methods. This makes the code easier to understand and interact with.
Many CRM projects I have worked on/inspected have had almost no code reuse partly due to the lack of classes created. Part of the reason is attitude, CRM developers don’t view creating reusable code as a priority.
CRM organised internal entities to make it easier to understand how it works. If we take security roles as an example.
The security role entity contains the main privileges which have a value of TRUE or FALSE and one of the four access levels Global, Business Child, Business unit, user.
Every time we add a new entity, we can set privileges for Create, Read, Write, Delete, Append, Append To, Assign, Share.
Whilst thinking about the example above I would except Privilege to be a separate class but we can see understanding the data in this structure is easier.
The clean coder has a good change on classes which talks about change isolating change
Needs will change, therefore code will change. We learned in OO 101 that there are concrete classes, which contain implementation details (code), and abstract classes, which
represent concepts only. A client class depending upon concrete details is at risk when those details change. We can introduce interfaces and abstract classes to help isolate the impact of those details.
Abstraction and modularity allows developers to work on separate parts of a system without having a detailed knowledge of the whole system.
Plugins allow developers to create new plugins without affecting other plugins. The crm dev needs to check there are no other plugins being triggered on the same entity. Good design of the code is based on on the plugin interface and not the concrete class e.g. your plugin.
The benefits of coding to an interface and using classes behind the interface is you limit the effects of change behind the interface.
You can add new types behind the interface without affecting any of the code which uses the interface.
A quick example is routing records to different users or teams, for this you could create an interface called Route and then concrete classes will contain the routing details and default value of the users/teams.
Route – Interface
The benefits of coding to an interface and using classes
Reading about the Dependency Inversion Principle (DIP) helped me understand abstractions and the benefits of using them. To remind you what DIP is
Depend on abstractions, not on concretions.
Wiki adds two more points to help understand
A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
I highly recommend you read Uncle Bobs article The Dependency Inversion Principle, where he explains it a lot better than me.
This article DIP in the Wild has a good example of using DIP which helps understand the concept and it’s usage in developer life.
Abstract ideas can be tricky to understand, to make this easier to understand think of black boxes.
Black boxes are code which works but the user of the black box doesn’t know how the code works inside the black box. The internal code can change but the consumers of the black box wouldn’t know.
Change has been isolated inside the black box, Interfaces and abstract classes operate as black boxes hiding the change behind them. Any code which interacts with an interface/abstract class won’t need to change if the internal workings behind the interfaces/abstract classes change.
A good example is using the CRM SDK to interact with the CRM database. Microsoft can change how the internal workings of the CRM SDK change and can change the CRM database structure (in CRM 2015 they removed CRM database extension table).
Microsoft removed a whole table but CRM developers who used the SDK wouldn’t have noticed any difference (I didn’t notice) but those who developed code/reports directly against the CRM table would suddenly find their code/reports no longer worked when they upgraded to CRM 2015.
The next blog in the series is how to find Classes
Business Applications communities