If
you feel it is a challenge in finding related elements from the monstrous
AOT, you are on the same page with me. AX is a composite application framework
that contains a mixture of feature implementations, but we developers need to
quickly identify the related elements when assigned with a task either to
develop a new feature or to fix an issue. This drives me to examining
modularization approaches in AX. I realized at least three ways
available: projects, naming convention, and models. Note, the word
modularization here means different from AX Modules, this is further
explained in the last section of this article.
Projects
Project
is used to organize developments - a project is a container of elements that
are to be modified or created new, to keep the development in one place. Since an element can be contained in multiple projects that may be worked by different people in parallel, conflicts may occur but can be resolved through team collaboration.
Beyond the normal use, we actually can also use project as a strategy to organize features. We can maintain two types of projects: development projects and feature projects,
differentiated with naming convention. A catalog of feature projects representing solutions for different business problems/areas enable us to quickly derive solutions for new development tasks.
Comparing to using models, projects are more handy and agile.
Models
According to official documentation, models are created for partitioning elements of solutions. An element can only exist in one model, and a single layer can have one or more models.
An
“element” that can exist in a model is granular than general thinking of
objects. E.g, a table method, a table field, or a class method all are the
elements, not just a table or a class as a whole. Actually anything that has a model
property that you can see from the AOT is an “element” (Fig.1). This approach actually
give a fair degree of flexibility on parallel development.
Figure 1. A element has Mode property |
It is helpful to realize that the legacyId property indicates whether an element is newly created in the layer (Fig. 2), newly created elements have legacyId = 0. For changed/overlaying elements, we can review the
changes by comparing between implementation layers (Fig.3).
Figure 2. A element has LegacyId property |
Figure 3. Comparing an
element from two layers
|
While using models we can retrieve the elements of a model through AXUtil and AX Management Shell
commands both for a summary and for a detailed list (Fig. 4), we also can do so through the model management GUI.
Figure 4. Use command utils to view and manage models
|
Naming
Convention
Projects
don’t enforce cohesiveness, while models do but generally in a larger granularity. For
example, both don’t support in finding the tables and classes for General
Leger management. Here what really help is naming convention.
As
shown in following screenshot of the AOT (Fig. 5), naming convention clearly
demonstrates its criticality for grouping elements and partitioning solutions. Further down the road, new
development requires to maintain and create naming schemes, especially in a
team environment.
Figure 5. Naming convention in AOT |
A
Side Note for AX Modules
AX module is a concept representing functional area partition in terms of entry points - the Menus. It has nothing to do with the concept of layers, models or
projects etc. In fact, different AX modules can have components from the same layer and the same model (Figure 6 shows layers and models installed that contains components for all AX modules). AX modules are not for partitioning solutions and development.
Figure 6. Installed models by model management tools |
Finally, notice the two aspects of partitioning: the development/project and the solution. As pointed out earlier, projects provide divisions only for developments, as compared to the sense of models that partition solutions that are corresponding to business features or functional areas. So model is the main tool to achieve a clean-cut, modular solution structure in AX. To this regard, I would say that we have under leveraged the model as a partition strategy.
No comments:
Post a Comment