AX 2012 Design Patterns: Instantiating Objects

Recently I created a resource blog post, focused on AX 2012 - Design Patterns Overview. There are a lot of things we need to understand about design patterns with Microsoft Dynamics AX 2012. The return, and value in understanding these, is being able to have correct designs, when working with custom scope.

With that, lets take a little look at some of these. First up is: Instantiating Application Objects Design Pattern. What's interesting about this design pattern, is the very first thing you read from the post on MSDN.:

"You must use menu items to open application objects instead of opening them directly. Menu items can be seen as APIs to the application. They are an abstract layer (interface) between the user and the actual application object that implements the functionality. Changes to application objects are automatically reflected in the user interface when menu items are used."

Menu Items, have always been used actually, around objects like Forms, Reports, and Action classes. These action classes, usually were focused around RunBase and RunBaseBatch. That is being replaced with the SysOperations Framework however. Still, the SysOperations Framework, or Business Operation Framework, artifacts are surfaced to the user and controlled by this API of menu items.

Once more, we have some nice Community content on this specific design pattern, from Martin Dráb.:

Notice that FormFunctionButtonControl class has a menuFunction() method. It allows to easily access MenuFunction instance on forms.
For example, you can define custom parameters in menuitembutton's clicked() in this way:

Args args = new Args();

if (something)
    args.record(ds1);
else
    args.record(ds2);

this.menuFunction().run(args); 

So the idea should be firm then, in that when possible Menu Items are what should be used to instantiate an object. Now there are other times, in which you need to instantiate and object that a menu item just does not fit the bill. In those times, you should use the ClassFacotry.

Doing this, will make sure any subclasses will fire correctly, and that the correct sequence of calling an object like a form, report or action style class is properly handled. There is a big note on this design pattern, that changes what has been used in the past for AX. That is: Never use the FormRun or ReportRun methods for directly instantiating an object.

A lot of developers, and customization's have been done in the manner in the past, and this is a big no no, now. Keep this in mind when doing actual development work. Of course, you still have custom class objects, and table objects within X++ code, that have a static create, or a new() call to work with them. However even with these concepts, if you can use the design pattern of making use of menu items for these scope and need as well, then you have a layer of abstraction that can be used to connect, and help drive parameter based callings of an object.

Well I hope this helps in our first dive into the design patterns in AX 2012. I think this is a very important one for developers to understand. The FormRun and ReportRun is something I've seen a lot, and in earlier versions of AX development I used myself.

That's all for now, check back soon as more to come. Till next time!

"Visit the Dynamics AX Community Page today!"