The easiest way to describe patterns and frameworks is to state that patterns describe how we perform a task, and a framework is the existing code that we use or extend. Both are very important.
Although patterns do not contain actual code, they are critical for ensuring that what we write is consistent, extendable, and easy to understand by members of our team. This removes a lot of thinking about how a task is performed, so we can focus on the actual problem.
A good example of how patterns can be used is demonstrated by the following requirement: we require a method to edit the customer credit limit from the customer list page. This should be a button on the action page that will open a dialog, showing the current credit limit and allowing the user to update it. When the user clicks on OK, it will update the customer's credit limit.
There are many ways to do this, and it may seem appropriate to create a form that initializes from the current customer on the list page, and updates the record when the user presses OK.
This is until we get the next series of requests:
Can we add the button to the collections list page?
Can we add the button to the sales order form?
Can we run a routine that validates the open sales order?
Can we place the resulting sales orders that fail the credit limit in a workflow?
The preceding requests are clearly additional work, but the code should require only extending and not rewriting. What often happens is that the design is changed to such an extent to try to fit the requirement that it is barely readable by the original developer.
The actual design we should have adopted would be similar to the following:
The form, instead, interacts with a data contract, which is initialized from the caller
A handler class is written to take the data contract (which contains the new credit limit and the customer to be updated) and makes the necessary updates
A data contract is a class that has a set of public properties that form a structured dataset, allowing the data to be passed to and among objects. They can also cross tiers across the architecture and be marshalled to external services.
The additional work is to create two classes and about 10 lines of code. This will make the solution much easier to extend, and if adopted by a team, easier to read and maintain.
Many development teams spend some effort in adopting patterns, and sometimes evolving them over time. We have many patters in AX, and most of the tasks we need to perform can be done by following an existing pattern.
Microsoft has published the reference patterns that we should follow at Microsoft Dynamics AX Design Patterns, http://msdn.microsoft.com/en-us/library/aa851876.aspx.
The frameworks in Dynamics AX are designed to be either used or extended. They are often a complicated set of tables and classes, and sometimes contain a user interface. We take advantage of them by extending and/or implementing a specific class.
Most of the key functionality in AX is accessed through the existing business logic; this is true for some master data tables, and certainly true of all transactional data.
For example, in order to post a sales order confirmation, we would use the FormLetter framework. In this case, the framework provides the FormLetterService class, which has the postSalesOrderConfirmation method.
Other frameworks are designed to assist us in common development patterns or provide access to features that are not directly accessible from X++. In the preceding example, we could've used the SysOperation framework, which allows us to interact with the batch framework, thereby allowing asynchronous code execution.
We will use and extend these frameworks as we progress through the chapters.