RecordContainers
A RecordContainer defines how an Entity loads, writes, filters, sorts, and maps its records. It is the data access layer of the Entity model: the Entity contains the business-oriented structure and behavior, while the RecordContainer connects that model to the actual data source.
Role in the Entity model
The RecordContainer is the abstraction layer between the Entity model and the source that provides the data.
This separation allows the same Entity model to work with different data access strategies. For example, an Entity can use a dbRecordContainer for regular database access and another RecordContainer for a search-oriented or manually assembled data source.
Depending on the use case, more than one RecordContainer can be defined for one Entity. One example is KeywordEntry_entity in module keyword of the ADITO xRM project.
What this chapter covers
This chapter links to the main RecordContainer types:
| RecordContainer type | Use case |
|---|---|
dbRecordContainer | Relation database-backed Entities. This is the usual starting point for most projects because it maps EntityFields to database columns and automatically handles the common SQL operations. |
JDitoRecordContainer | Custom loading logic, manually assembled records, or external data sources such as web services. |
IndexRecordContainer | Search-oriented scenarios, especially when data is read from a search index. |
DatalessRecordContainer | Input-oriented scenarios where the Entity does not need persistent storage. |
For most projects, dbRecordContainer is the most used RecordContainer type.
It has the lowest implementation overhead if the Entity data maps cleanly to database tables and columns.
Use another RecordContainer type when the data source, performance requirements, or interaction pattern cannot be represented by the database RecordContainer.
Caching
A RecordContainer can use a cache to improve performance for repeated requests of the same data. This is described in RecordContainerCache.