Sisyphus Persistence Framework

Project Page

Download

Manual

Overview

The aim of Sisyphus Persistence Framework (SPF) is to greatly simplify the reoccurring problem of how to validate and persist objects. Much like Sisyphus had to keep rolling a boulder up a hill, we coders have to keep rolling our own code time and again to do the same tasks. These tasks include persisting objects, validating objects, editing objects and searching for objects.

SPF is a set of classes that makes these tasks, amongst others, really straightforward. If you create an object, it will create the database table for you. If you say an object has a collection of children then SPF will maintain that for you. If you specify that an object has certain constraints then SPF will ensure that those constraints are always checked. The aim is to free up the developer to concentrate on the domain problem and to let SPF take care of the mundane tasks.

Using SPF

At its simplest, all a developer has to do to take advantage of SPF is follow the instructions below:

1. Subclass SpfEntity
2. Model object values as primitive public fields
3. Provide a parameterless constructor

If the above conditions are met then the object is ready to be persisted via SPF. For a full example see the Hello SPF tutorial.

Key SPF Concepts

Entities

An entity represents a business domain object, e.g. a user Each type of entity has a set of fields. The values in these fields represent the state of the business object. An entity maps onto a single table in the store. The name of the table is either specified using an attribute or inferred from the entity type name.

Data Types

Each field of an entity has an associated data type which defines what values that field may contain. If any field contains an invalid value then the entity cannot be saved to the data store.

The data type of a field is either specified using an attribute or inferred from type of the field. SPF comes with a set of in built data types covering primitives and enumerations. If necessary, custom data types can easily be created, e.g. postal code.

Constraints

Each entity type has a set of constraints that must be met for the entity to represents a valid business object, e.g. inception date must be before the expiration date. An entity cannot be saved to the data store if any of these constraints are broken.

Constraints are implemented within the entity class as delegates. These delegates are added to the base object in the entity constructor as can be seen in the constraints tutorial.

Triggers

Each entity type has a set of triggers which represent business logic that is called when certain actions occur, e.g. a welcome email is sent when a new user is added.

Triggers are implemented within the entity class as delegates. These delegates are added to the base object in the entity constructor, as can be seen in the triggers tutorial.

Criteria

A criteria object defines a set of entities of a certain type. This set can be parameterised by passing arguments to the constructor of the criteria object. Criteria object instances can be used to retrieve and delete sets of entities, as can be seen in the criteria tutorial.