Book Image

Learning Dynamics NAV Patterns

By : Marije Brummel
Book Image

Learning Dynamics NAV Patterns

By: Marije Brummel

Overview of this book

Microsoft Dynamics NAV is a complete ERP system, which also contains a robust set of development tools to support customization and enhancement. These include an object designer for each of the seven application object types, a business application-oriented programming language with .NET interface capability, a compiler, a debugger, and programming testing language support. Learning Dynamics NAV Patterns will guide you through the NAV way of solving problems. This book will first introduce you to patterns and the software architecture of the NAV and then help you to build an example application. Then, it walks you through the details of architectural patterns, design patterns, and implementation patterns. This book will also talk about anti-patterns and handling legacy code. Finally, it teaches you to build solutions using patterns. Proven patterns and best practices will help you create better solutions that are easy to maintain in larger teams across several locations. It will guide you through combining abstract patterns using easy-to-understand examples and will help you decide which patterns to use in which scenarios.
Table of Contents (9 chapters)
Thank you for buying Learning Dynamics NAV Patterns

Building blocks

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.


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.


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.


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.


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.


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.


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


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

To learn more about these object types and what you can do with them, please read Programming Microsoft NAV 2015, by David Studebaker, published by Packt Publishing.