Forgive indulging in a bit of pattern obsession, but Joist uses several concepts and terminology from Fowler’s PoEAA to drive its features.
Specifically, with the links to their implementations:
Unit of Work–coordinates dirty object tracking and validation
Identity Map–ensures entities are represented by only 1 instance-per-UoW
Data Mapper (with Meta-data Mapping)–loads data out of
ResultSets and into
PreparedStatements using meta-data in
Alias classes generated at build-time
Foreign Key Mapping (with automatically-maintained back pointer)–loads lists of objects on demand (e.g.
Lazy Load (with value holder, e.g. no virtual proxies)–loads objects on demand (e.g.
Class Table Inheritance–allows modeling inheritance (Joist doesn’t support Single Table Inheritance or Concrete Table Inheritance)
Optimistic Offline Lock–every object has a
version column to ensure that stale data does not overwrite fresher data
Finders–though called queries as they can also do bulk updates/deletes
Transformer Generation–input model of database schema is transformed into a Java model
Generation Gap–user-modifiable class is output just once with boilerplate in the superclass