Base entities

All entities will have the soft delete implementation. The base data access implementation will take care to only read the non-deleted entities.

All entities will be implementations of a base class that will implement the generic data access through various methods such as:

• direct database access through the ORM
• API
• cache (some entities should be marked as cacheable, enums or user credentials for example) etc. and some data can be marked as non-cacheable (tables with frequent updates or data that must be up to date always). Some entities can have the cache option missing ant it will be up to the user to decide the cache’s usefulness.

The business logic user/programmer will be unaware how the data is obtained and its source (unless debugging). Data will be gathered by the active implementation without user intervention.

An ORM will be used in order to facilitate the entity design.

Some records or fields should only be displayed or returned according to the user’s credentials. See the security section.

Some fields should be able to be marked as read-only (see enums) and should be writeable only on creation (seeding).

For read operations, the API should allow to specify only the fields (deep level with .) that must be read or this information can be taken from the user’s role.

The Read Query should implement deep level (JOIN) where, filter and sort functionality.

All data returned to the UI should be for display only, i.e. filtered, validated and processed.

Data that results in UI changes (for example icon display) should return objects describing the display objects. Avoid business logic in the UI kernel. For example, you can return parsed HTML content to be displayed instead of values that change UI behavior or reference UI components that are activated to process the data.