Tuesday, September 2, 2014

Development Standards for Dynamics CRM

In xRM development, nearly every solution requires some custom development in order to extend Dynamics CRM for business scenarios outside CRM functions such as sales force automation and customer service.  As with any software development, strong naming standards will help your developers and testers save time and produce a better solution.

Here are some modest suggestions:
  • Be generous in comments inside your code.  The next developer who takes over will thank you.
  • Provide unified coding standards on the JavaScript libraries.
  • Use consistent file naming conventions.
  • Use only one .JS file per form for the form-specific logic.
  • Don't write JavaScript event handlers from the control property window rather than as part of the JavaScript file associated with the form.
  • Create standard common function libraries, to address common functionality across forms. 
  • Use JavaScript or business rules (in Dynamics CRM 2013) to show/hide/enable/disable controls rather than creating multiple similar forms.
  • Be consistent in designing the user interface, using the same control types with an eye toward the user experience.


Joe Newstrom said...

Hi Jim,

When you say use one .js file per form, but use multiple common libraries... are you saying that, in your opinion best practice would be to duplicate blocks of code in each .js file?

I can see this becoming a maintenance nightmare, and given that client side caching is the norm, am curious why a single .js file per form is your recommendation.

Thank you in advance,


Jim Townsend said...

Thank you for reading the post and for your helpful comment. I should have said one file per form for the form-specific logic as opposed to a shared library. I will update to reflect this.

Dmitri Riz said...

The best practice, for complex projects, is to use a customized solution build process.
All CRM artefacts should be contained within a CRM Packaging project (that gets added as part of CRM Dev Toolkit part of SDK).

Contents of packaging project get published during one of build steps.

Each form should load just one js web resource for performance and reliability.

If form needs multiple libraries to run (e.g. jquery, angular, … your custom js code), than resulting single form-level js web resource should be created during a special pre-build step from its constituting parts.
In the example above, you will have, in your VS solution, a folder or folders with individual JS files – 3 files in this case.

Pre-build step will (optionally) minify resources and append them together in an appropriate order in the single file (contained and managed by the Packaging project).

Also, during this prebuild step, you can validate resulting js using something like jslint, and terminate build if error count exceeds max.

When single form-level files are created, build process continues as usual – building other .NET assemblies, publishing CRM stuff etc.

Richard Foster said...

I'm sure now there are a lot of systems that match these standards. For example this https://www.bitrix24.com/uses/free-sales-management-software.php is a great software which helps me in my work projects and works very well and I did not notice any lags.