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