Wherever you look in life, you see patterns. Even life itself follows a pattern. Patterns help us in being organized by giving us structure, which makes things easier for us to understand. Without structure, we start being stressed and disorganized.

As this is true for many things in our lives, this is also true in computer programming. Applying structure in our computer programs make them easier to understand and maintain. Each profession has patterns that have proven to be successful in certain conditions, and unsuccessful in other conditions.

Software design patterns

Good old Wikipedia defines software design patterns succinctly as "A general reusable solution to a commonly occurring problem within a given context in software design." By nature, people look for ways to get organized and structured. It is not a surprise that during the 1970s and 1980s people started to look for structures in computer programming, which was a new, fast growing business.

You can read more about the software Design Patterns on Wikipedia at https://en.wikipedia.org/wiki/Software_design_pattern. Software design patterns, especially in object-oriented programming (OOP), gained popularity in the 1990s when after Design Patterns: Elements of Reusable Object-Oriented Software was published by the Gang of Four, Erich Gamma, Chard Helm, Ralph Johnson, and John Vlissides. They published 23 classic software design patterns. Since then, many other patterns have been documented. Many of these were based on object-oriented programming, but people also started to document patterns outside this context.

The Procedural software design patterns

The product that we work with, Microsoft Dynamics NAV, has a programming language that people refer to as Procedural. It was invented in the 1980s and is based on Pascal, which is a very popular programming language that is still loved by many.

In this article, Paul Ford explains the history of code, procedural languages, and object oriented programming at http://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/#b06g24t20w15.

As with everything in life, we seek structure, hence we can apply software design patterns to Procedural languages. We just need to look carefully at all the object-oriented content that is available, and cherry-pick what applies. We can then complete this content with specifics of our language.

Procedural languages preceded the more modern object-oriented languages. One of the challenges that object-oriented programming is trying to solve is grouping things together that belong together. For this, classes are used. In this book, we will attempt to do this as well by treating tables and codeunits as a class, and then grouping functions together accordingly.

The base application that is shipped with Microsoft Dynamics NAV is full of design patterns, general reusable solutions to a commonly occurring problem within a given context in software design. Using these patterns when applicable, not only do you use solutions that have proven to work, but you also create software that people recognize as Dynamics NAV, since it will probably behave the same as the standard software.

The object-oriented patterns

The most well-known object-oriented patterns are those that are documented in the book called Elements of Reusable Object-Oriented Software, which we mentioned earlier in this chapter. Examples of these patterns are Builder, Prototype, Bridge, Singleton, Façade, and Adapter. We reuse some of these names in this book when they resemble the original pattern. Another object-oriented pattern is the Model-View-ViewModel (MVVM) pattern, which also applies to Dynamics NAV.

Non-object-oriented patterns

The base design patterns from object-oriented programming are pretty much targeted at structuring applications, running as Windows services or applications. With Microsoft Dynamics NAV, we get all of that out of the box. We don't have to think of how to get the data from the database, or how to handle concurrency.

For a better understanding of object-oriented patterns and why they don't apply to Dynamics NAV and C/AL, please read and watch the information at http://www.newthinktank.com/2012/08/design-patterns-video-tutorial/.

The functional oriented patterns

The patterns that we use in Dynamics NAV typically are functionally oriented. They are sometimes even focused on the typical ERP problems, such as storage and formatting of address information. They still solve commonly occurring problems.

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.

To develop solutions in Microsoft Dynamics NAV, we have seven main building blocks. These blocks determine the behavior of our application together with the programming code.

The following screenshot shows the Object Designer that allows the development access to the main building blocks:

Let's go over these one by one.

Table

The Table object allows us to define how the data is stored in the database, as well as in business logic.

The only database option for Microsoft Dynamics NAV is Microsoft SQL Server. The SQL Table definitions are automatically created, based on the Table object in Dynamics NAV.

All the business logic is handled by the Dynamics NAV runtime. The SQL Server options, such as foreign keys, triggers, or stored procedures are not used.

Unlike many other applications, Dynamics NAV is not fully normalized, given a few exceptions. Tables are bound one-to-one with the user interface. This adds a certain level of simplicity to the design that makes it easy to understand and work with. It also allows us to store historical information in a relatively simple way. For example, the customer address is copied to the posted invoice, as it was the time the invoice was printed.

This way of designing tables is crucial to understand when we deep dive into the design patterns in the later part of this book.

Page

The user interface of Microsoft Dynamics NAV is defined using the Page objects. This is done by a combination of binding a Page object to a Table, and adding metadata.

The designer is not what you see is what you get (WYSIWYG) as we design for multiple display targets using one object definition. This makes defining the UI a highly abstract task.

The Page object inherits all the properties and methods from the underlying table. Developers have the option of adding additional properties and methods, as well as business logic that is specific to the behavior of the object.

All the logic to Create, Read, Update, and Delete (CRUD) from the database is automatically generated by the system. This makes it very easy to work with, but also enforces the relationship between a Page and Table.

We can overrule this by implementing the Model-View-ViewModel Pattern, which we will discuss later in Chapter 3, Architectural Patterns. This pattern allows us to have a UI, which is unbound to the way the data is stored in the SQL Server database.

Report

In Microsoft Dynamics NAV, the Report objects are used for both: printing documents, and creating batch routines for data modification.

Reports are typically used to print business documents such as invoices, reminders, and balance due lists.

In addition to printing, they act as containers for batch processes, such as combined invoicing and batch posting. The reasons for using reports instead of codeunits are the possibilities of adding the UI (request page), and the built-in iteration capabilities.

This object type is outside of the scope of this book, although we occasionally mention it when describing patterns.

Codeunit

When writing business logic, Codeunits are the preferred place to do this. They act as containers for the code that allow us to structure our programming using known concepts such as encapsulation.

In this book, we will discuss different types of codeunits that are used as part of the design patterns, as well as best practices to structure our code.

We will discuss how, and why codeunits should be used for code in Chapter 5, Coding Best Practices.

Query

Most business logic in Microsoft Dynamics NAV is bound to the table object, since the table behaves as a class with methods and properties.

However, when using complex iterations over many data items, it can be costly to loop over them one-by-one.

To solve this, we can define Query objects that act as predefined SQL Server queries, allowing us to join multiple tables in one read and only read the columns that we need.

XMLPort

To interface with Microsoft Dynamics NAV, we can use XMLPort objects. They are outside the scope of this book.

MenuSuite

The MenuSuite object helps us to search the application. They are outside the scope of this book.

Table objects behave as classes in Microsoft Dynamics NAV, and are the base of our application. They are bound to tables in the SQL Server, and need to contain all the fields that will be used in the Page objects.

This does not mean that we cannot add references to other tables in a table object. We can reference to other tables using Flowfields and Flowfilters objects.

Flowfields

When we define a field in a Table, it gets added to the SQL Server table definition automatically, unless we change the FieldClass property. Flowfields and Flowfilters objects are only a part of the Dynamics NAV Metadata. They do not exist as a part of the SQL Server table definition.

If we change the property, we can join fields from other tables that we can display on all the Page objects, since they are treated as normal fields. We can also use them in C/AL code for filtering and sorting. The latter is a new option in Dynamics NAV 2015 where we can, for example, do GLAccount.SETCURRENTKEY(Balance). This used to be impossible.

The following screenshot shows the property in the Object Designer:

Flowfilters

When using Flowfields, you can use any field in the table as a where clause. However, sometimes you might need values that are set by users at runtime. This is what Flowfilters are used for. They are defined as fields in the table, but are not added to the SQL Table definition, or available as filter or sorting criteria.

Most development projects in Microsoft Dynamics NAV don't start from scratch as empty projects. They often start from the base application that Microsoft ships. This is an ERP application that allows their users to streamline business processes.

The application originated in the 1980s just as the programming language did, and has grown organically since its first introduction.

To be an excellent Microsoft Dynamics NAV developer, understanding business processes is maybe even more crucial than understanding the language, objects, and design patterns.

Functional processes

Microsoft Dynamics NAV allows you to administer many of the functional processes. Although they all have different purposes, such as general ledger, inventory, sales, purchasing, jobs, and manufacturing, they all use the same elements that make the application recognizable for the end user.

If a user is able to post something to the general ledger, it is very likely that they can easily understand posting to the inventory. Posting sales and purchase documents have the same similarities.

This is possible by using the same structures across the application. This also makes it easier for developers to learn new parts of the application.

Many of these structures have been in the application for a long time, since they are very closely related to ERP programming. Others have been added more recently, since they are more related to intuitive UI in correlation with app-like programming.

To learn more about these functional areas and what you can do with them, please read the Microsoft NAV 2013 Application Design book by Marije Brummel, published by Packt Publishing.

In this chapter, we have learned what design patterns are, and how they started and were introduced in computer science. We learned how design patterns can be applied to Microsoft Dynamics NAV. We also learned about anti-patterns.

In the next chapter, we will build a small application in Microsoft Dynamics NAV that consists of different design patterns brought together.