patterns

Active Record vs Data Mapper

Active Record as the ORM layer

Most Object Relational Mappers implement the Active Record pattern which is just an overloaded form of the Row Data Gateway pattern.

In both the Row Data Gateway and Active Record patterns, a single object corresponds to a single record in the database. The Active Record merely allows for business logic to be contained within the same object that contains the data access logic. So in a single object you would find both an insert() method and a doSomeBusinessFunction() method.

Data Mapper as the ORM layer

The Data Mapper pattern is at once more complex conceptually and at the same time simpler because it uses two or more types of objects where the Active Record pattern would have used one. At the minimum, utilizing a Data Mapper requires creating a Data Mapper object and a Model or Domain object.

In the Data Mapper pattern, methods like insert(), update(), delete() exist only in the data mapper and the domain object would contain only business logic and related methods like doSomeBusinessFunction().

In addition, a Data Mapper is designed to map fields and metadata from multiple data resources into a single model or domain object.

Design Patterns

Gacela implements the following patterns from Patterns of Enterprise Application Architecture by Martin Fowler:

Data Mapper

Provides a translation layer between data storage (RDBMS, web service, xml, etc) and the domain objects which consume data from these data sources.

Foreign Key Mapping

If a resource contains a foreign key to another resource, then the resources can reference each other. Generally on one side is the resource that 'belongs to' and on the other side is the resource that 'has many'. Association Mapping is special kind of foreign key mapping.

Association Mapping

In a situation where two resources are related through foreign keys, but both sides are a 'has many' type of relationship. This results in a special 'has and belongs to many' type of relationship.

Dependent Mapping

Resources (tables) exist only with the context of a parent resource. For example, phone numbers may be stored with a user id but should not be loaded as separate domain objects but rather as a field in the user object.

Concrete Table Inheritance

If a resource inherits from a parent resource, then all fields in the parent resource are available in the child resource.

Query Object

This is implemented in two ways in Gacela. First in the Criteria object which is used to pass criteria to mapper methods for loading data.

Second, each data source has a Query object which provides the facility to dynamically build queries in a format compatible with the specific data source.

Metadata Mapping

Foreign key relations, inheritance mapping, association table mapping, field names and meta information are all pulled directly from the data source whenever possible. This information can be cached in files thus reducing overall load on the data source.

Lazy & Eager Loading

Data can be loaded using an eager or a lazy methodology. Eager loading is when you load data before it has been requested. Eager loading generally works best when you know that you will always need a particular set of data for every request. Lazy loading is when you wait to load data until it is requested. Lazy loading generally works best when you don't know beforehand what data will be needed.

In Gacela, unless dealing with an inheritance or dependent relationship, data is always lazy loaded.