Where to Place the Code

Article
05/18/2015

Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

Correct code placement is essential for good application performance (especially in the client/server environment) and to make the application easy to customize, reuse, navigate, and maintain.

3-tier Design

Optimize your programs to utilize the 3-tier architecture that is supported by Microsoft Dynamics AX.

Tier	Objects and code belonging to the tier
Client	Presentation layer. This is where forms are stored. Place client-specific classes and methods here.
Object server	The location of business application logic. Transaction-oriented database update jobs should be placed to run here, close to the database.
Database server	Utilize the power of the database server by using aggregate functions, joins, and other calculating features of the database management system.

Classes

Put code in the classes that are:

Related to many tables, such as update jobs

–or–
Not related to tables, for example, various supporting activities

Create class instance methods:

When working on the instance variables of the class (objects of)

–or–
When overriding is potentially useful

Create class static methods when:

Access to the class instance members is not needed
Overriding is not necessary
The functionality of the method is related to the class it is defined on
The method might be able to execute on a different tier than the method's

Tables

Put code that is strictly related to a table as methods on that table.

Create table instance methods for handling one record at a time. Create table static methods when handling none, some, or all records.

Split code to be executed on separate tiers into separate methods.

Note

Do not create instance methods when no instance is needed.

Code in static methods can technically be created anywhere—on any table or class—because it has no physical binding to the instance. Create it either on the table or on the class where it logically belongs.

The Global Class

Place methods in the Global class if they cannot be placed more logically on another class (or table).

Methods on Global should have the same character as the system functions. They should be general-purpose, tool-extending, and application-neutral.

Do not use the Global:: prefix when calling Global methods—methods on this class do not need a variable declaration.

Forms and Reports

Do not put any code in forms or reports except for calls to the classes and table methods that handle complex layout and business logic.

Do not to place edit and display methods on forms and reports if they can be placed on a table.

If code cannot be avoided in the form:

Place the code at the data source/data source field level and not at the control level.
Call classes from buttons on forms by using menu items (for example, by not using code).

Maps

Use maps for a limited number of connected fields. For example, for the Address fields, code should be placed on AddressMap.

Views

Views are limited select statements used on read-only tables. Do not place much code on views, unless, for example, you have a display method on the parent table.

Share via