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.

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 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.