Patterns elements and hierarchy

Many books about patterns use different ways to categorise them. Patterns are closely related to the application building blocks, such as tables, fields, functions, and codeunits. Patterns will help us categorize these elements, so that we can learn different table types, and codeunit types.

Architectural patterns

When a pattern describes table definitions or a methodology to move data from one set of tables to another, we refer to it as an Architectural Pattern.

By learning Architectural patterns, we understand how the application's large building blocks are constructed. There are only a dozen of these patterns that are most commonly used. Examples are Master Data, Journals, and Rules tables.

This does not mean that any other way of designing tables and moving data is wrong by definition. It might just not be a common way of doing it, making your code harder to understand for others, and less easy to maintain.

Design patterns

Any pattern that is not related to the table definitions, or moving data in the database, is a Design Pattern. There are dozens of patterns, and in this book we'll only focus on the ones that are most commonly used, such as number series and entity state.

Structuring code

Even if you follow the patterns in this book step-by-step, your solution will be hard to maintain if you don't bring structure to your code. There are standard ways and best practices for doing this. You can find a lot of them online, mostly related to object-oriented programming, but also outside of object-oriented programming.

We can translate these best practices so that they can work with C/AL. This will help us implement best practices in Dynamics NAV, which are widely accepted in computer science.

The coding standards

The readability of your code depends in large part on how you handle variable naming and code punctuation.

For Microsoft Dynamics NAV, a wide range of documented standards are available that we will discuss in detail. Following this standard will enable other developers to read your code with ease, and seamlessly integrate your code into standard code. Remember, Microsoft Dynamics NAV offers access to the entire source of the application, so it makes sense to follow standards that are already applied throughout the standard code.

This makes it easier to clone (copy) parts of the application.

Anti-patterns

Where there are best practices, there can also be ways that are proven to be less productive. These are referred to as anti-patterns. Anti-patterns are bound to context, which means that a good pattern applied to the wrong problem can be an anti-pattern.

Code cloning

A typical example of an anti-pattern in computer programming is code cloning. This means copying and pasting similar code in your application rather than normalizing it into classes and functions. Code cloning is applied in Dynamics NAV in large proportions.

When working with C/AL, being able to copy a part of the application and making it specific to certain needs is considered powerful.

This does not yet make code cloning a good thing. We will explain good and bad examples of code cloning, and help you with a set of criteria about when cloning can be applied, and when it should be avoided.

There are many good and bad examples available in the standard application. We will discuss them in Chapter 6, Anti-patterns and Handling Legacy Code.

Legacy code

The Microsoft Dynamics NAV application code started being developed in 1980s, and grew organically.

Despite the fact that the original architect applied many patterns, we still know today from the very early days we can safely say that many parts of the application are not optimized in a way they could be if one would have the opportunity to start over.

Handling legacy code is highly important for the lifecycle of your application. Thousands of companies have been using Dynamics NAV for more than two decades, upgrading their solution every few years to the latest version.

To provide this upgrade opportunity, one should be careful when redesigning the application.

This makes it even more important to start with the correct patterns from the beginning.

Especially when dealing with limited resources, a situation that most Dynamics NAV development centers face, we want to spend as much time as possible in making new features instead of fixing issues or rewriting existing code.

We will discuss examples of how the legacy code in Microsoft Dynamics NAV was preserved, and how and when it was updated when necessary.

Upgradability

Microsoft Dynamics NAV has a great track record of being upgradable from one version to the next. It is possible to upgrade all the way from the earliest MS-DOS versions of the product to the latest version running on Azure in the cloud.

This requires the application architects to be very careful in making decisions. Changes made to the application may live for many years or even decades.

When upgrading to newer versions, there are two big challenges.

• Code Upgrade: each time Microsoft ships a new version of the product, we have to see if the changes that we made to their code still function as intended. This requires not only merging code and testing of the application, but also doing a fit/gap analysis each time new functionality is added to the base application.
• Data Upgrade: if there are changes in the way the data is stored in the table objects, we have to provide software programs that convert the data from the old structure to the new structure. This is referred to as the Upgrade Toolkit for Microsoft Dynamics NAV. You will learn about this in Chapter 6, Anti-patterns and Handling Legacy Code.

The upgrade frequency

Traditionally, customers used to upgrade the software every few years. The initial version is the active release when the implementation of a project starts. After go-live of the project, a system would typically not be touched, most often because of the upgrade cost.

Microsoft used to ship major releases of their software every few years. For customers, it was considered best practice to upgrade every other major version, depending on the return on investment.

This image illustrates this practice:

However, this best practice of upgrading has shifted dramatically with the introduction of a connected world, internet, and cloud. There is an increasing demand for being up to date with application software, and always being current.

New technologies are introduced in a higher frequency than ever before, and this has impacted the way Microsoft ships the Dynamics NAV product.

We changed to yearly release cycles and frequent rollups, which often contained new features, and new technology. Instead of upgrading every few years, there is a requirement to be (almost) always current on version, as illustrated in the next image:

This methodology is especially important when running in a Multi-Tenant environment, where individual customers no longer have a decision in their upgrading strategy.

Design patterns and upgrades

The cost of making the upgrades can be reduced by avoiding conflicts, and/or by automatically resolving conflicts. Implementing design patterns and coding best practices can help us achieve this and make upgrading easier.

Delta files

Another method to reduce the costs of shipping and merging software is using the delta files, which were introduced in 2014 by Microsoft.

Delta files are based on flat text definitions of Dynamics NAV objects, and are handled by PowerShell commandlets. The algorithms can create and apply text files on all the versions of Dynamics NAV—from 2009 and forward.

The Delta file describes, as the name implies, the delta between two objects in such a way that they can be applied to other systems quite easily. This saves time and money in merging the software.

Repeatability

In a cloud-first mobile-first world, repeatability becomes increasingly important. Where barely 20 years ago consultants were driving around in their cars to customers to install software and explain its use, there is an increasing trend towards click-try-buy ERP systems.

In this ecosystem, intuitive use is very important. Microsoft has invested in a user interface that makes it easier to use Dynamics NAV from a metadata perspective. However, to be really more user friendly, the metadata (UI) needs to be optimized too.

Design patterns and repeatability

Repeatable UI has been documented in Design Patterns. This makes it easy for developers to implement this in their own applications, and also makes the software work similarly across the application.

We differentiate between the classic and modern UI patterns. With multiple display targets and new devices, such as tablets being added to the product in an agile way, the UI patterns are a moving target and subject to change, version-by-version. An example of an updated pattern is statistics, wherein the classic UI totals were hidden; they are now visible on documents.

The following image illustrates an example of a modern UI on a tablet:

Lifecycle of a design pattern

Although design patterns are powerful when applied correctly, they can have negative side effects when applied in a situation where they should not be used. When choosing a design pattern to be used, it is important to see if it matches the requirements.

For example, when we need a table to store setup data, we might think of the Singleton pattern, but this only allows us to store a single set of data. If we need multiple sets, we might want to implement the Rules pattern. Both the patterns are documented in this book.

Technology changes

Design patterns can be made obsolete due to technology changes. Some languages have more built-in capabilities than others.

For example, C# has overloading, where the same function has different arguments. This is something that Dynamics NAV does not have. Therefore, we have a design pattern called the Argument table. This would be obsolete if we could overrule a function from the design time, or based on business logic.

The patterns in this book have been tested and documented for Microsoft Dynamics NAV 2015, but typically work in older versions of the product too.

Some of the design patterns in Dynamics NAV go as far back as the MS-DOS version of the product.

Old habits die hard

With technology changing, we should also question ourselves each time we design software, if we are still using the most optimal ways.

A typical example is this structure that we see a lot in the Dynamics NAV product; for example, in codeunit 81 Sales-Post (Yes/No):

OnRun(VAR Rec : Record "Table")

Table.COPY(Rec);

Code;

Rec := Table;

Code()

This code pattern started its life in the MS-DOS days, and just stayed in the application without being technically required. Developers apply it to their own objects just because it exists in many places in the standard application. We'll discuss alternative approaches in this book.

New design patterns

Sometimes, new technologies are introduced, such as charting. This then requires the new patterns that did not exist before. The following image is an example of a chart:

Other examples are patterns based on Query objects, and patterns for Activity Pages. Neither of these existed in the older versions, hence there was no requirement for Design Patterns.

Sometimes, we can reuse the existing patterns for new elements. The Activity Page uses the Singleton Pattern that we typically see for the Setup data. This adds new functional implementations for patterns, and the pattern documentation needs to be updated.

Developing SolutionsWriting software can, in many ways, be compared to building houses, or even building entire villages or cities. We need to plan ahead, but we also need to adjust to time. Things that we thought were brilliant in the 1990's are now considered old. Also with software, we need to maintain, rebuild, and rearrange as time goes by.

Software architecture in Microsoft Dynamics NAV

One thing that we need to consider when working with Microsoft Dynamics NAV is that both the metadata, and the base application deliver the base architecture for us. Unlike working in other development environments, programmers in Dynamics NAV seldom start from scratch.

Metadata

Much of the program's behavior is determined by metadata, which is interpreted at runtime.

The metadata is a combination of elements, methods, and properties that gives the program its unique behavior. This also limits the possibilities that developers have using the application that enforces a certain level of simplicity.

Understanding the Metadata and base application is core for achieving success in developing your own application. The patterns and best practices in this book will help you with this.