Application tables

Table objects are the foundation of every NAV application. Tables contain data structure definitions, as well as properties that describe the behavior of the data, including data validations and constraints.

More business logic is required in complex applications than in simple data type validation, and NAV allows C/AL code to be put in the table to control the insertion, modification, and deletion of records as well as logic on the field level. When the bulk of the business logic is coded on the table level, it is easier to develop, debug, support, modify, and even upgrade. Good design in NAV requires that as much of the business logic as possible resides in the tables. Having the business logic coded on the table level doesn't necessarily mean the code is resident in the table. NAV 2017 Help recommends the following guidelines for placing C/AL code:

In general, put the code in codeunits, instead of on the object on which it operates. This promotes a clean design and provides the ability to reuse code. It also helps enforce security. For example, typically users do not have direct access to tables that contain sensitpe data, such as the General Ledger Entry table, nor do they have permission to modify objects. If you put the code that operates on the general ledger in a codeunit, gpe the codeunit access to the table, and gpe the user permission to execute the codeunit, then you will not compromise the security of the table and the user will be able to access the table. If you must put code on an object instead of in a codeunit, then put the code as close as possible to the object on which it operates. For example, put code that modifies records in the triggers of the table fields.