Dynamics AX Development and Customization Best Practices-Customizing code

Developments are now shared among diverse team, sometimes across multiple partners and outsourced to vendors, meaning different skills and processes. Therefore such well known issues still remain in production when customized best practices rules and internal review are not properly defined.

Flexibility is maybe the number one strength of the product, but it can also leads into performance issues if the customized code doesn’t match the Microsoft Best Practices.

Optimize the code with the 10/10/80% application rule:

  • 10% of the performance can be explained by infrastructure issues like network, disk latency, memory pressure and high utilization processors
  • 10% by wrong configurations in SQL and AX such as Max degree of Parallelism, database files size and location, AX Database logging and Number Sequences
  • Then 80% can be found its root cause in the business logic X++ code in correlation with index tuning and data modelling.

I this article we will cover the Custom code standards and best practices.

  • If base layer code needs to be replicated or used at other places, it is always better to extend the existing classes and modify the derived class for the change in behavior, rather than creating completely new classes and then copying entire code from the base class.
    • Makes it easier to upgrade code:
      • When base layer code is changed, it must be replicated again.
      • If you have created an extension, only the modified code must be restructured.
  • Create classes and methods so that the same piece of code can be reused in multiple places.
  • Avoid creating long methods. They make code difficult to read, hard to debug, and extremely difficult to upgrade and maintain.
  • Remove dead code to avoid upgrade and maintenance costs.

Add custom code

  • Create customizations in the appropriate location.
  • Create code for reuse as much as possible.
  • Create it at the lowest appropriate location.

For example:

If anything is required only in a form do not put it at the table level.

The following examples describe where we recommend that you place the code:

If it is related to the UI, place the code on the appropriate UI elements, or create classes to handle scenarios specific to the UI.

For example: you can create classes that handle controls, number sequences in forms, dialog boxes, and so on.

  • If it is related to a business process, place the code in classes.
  • If it is directly related to tables and schema, place code on the tables.
  • Consume existing Microsoft Dynamics AX classes and services instead of directly querying tables.
  • Become familiar with the base layer features.
  • Do not write custom code that duplicates base functionality.

Important: Directly updating or deleting data from Microsoft Dynamics AX tables is not supported.

Coding standards

The following list provides coding standards to follow:

  • Favor the use of positive logic.
  • Use constants instead of numeric literals.
  • Use enumerations instead of constants.
  • Use explicit access modifiers.
  • Do not use method parameters as an l-value.
  • Arguments passed in a method should not be modified, and only the value should be used.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s