Repository pattern

The Repository pattern is the enterprise application architecture pattern for mapping in-memory object with the equivalent in the backing store. The repository knows about the backing store, the classes of elements that can be saves to the store and loaded from it. It provides a rich interface to query content and access related elements:

• EntityFramework calls the repository DbContext which can be used either as the data-model (with migrations to add to a relational store) or generated from the schema in a relational database.
• Hibernate calls the repository PersistenceContext. Hibernate has been adopted as the Enterprise Java Persistence API

HiLang implements the Repository pattern through the domain SubSpaces, that extends the generic SubSpace provided by Hiperspace.

Unit of Work

Closely related to the repository pattern is the Unit of Work pattern that layer transaction (all or nothing) consistency on top of the Repository to ensure that complex business entities are consistently record in a store. Transactions are important to relational databases because a single business entity like order is stored across multiple tables in the database. Because multiple tables must be updated, a common pattern is to save changes once at the end of a session, and often to use a message queue / memory-cache update the database.

There was less need for unity work with hiperspace, because elements can represent full business entities up to two gigabytes in size. Where complex transactions are still required SessionSpace provides all-or-nothing transactions.

Persistence frameworks often use a timestamp property to provide Optimistic concurrency control to avoid the complexity of holding long-lived-locks in the underlying store. In Hiperspace, elements are either immutable and cannot be changed, or versioned to include history. Even in the worst case of conflicting updates, history can be used to reconcile differences.

Command Query Responsibility Segregation (CQRS)

"CQRS, or Command Query Responsibility Segregation, is an enterprise pattern that builds upon the Unit-of-Work pattern. It separates the tasks of updating a repository (known as a command) from querying it. This pattern was initially developed to address the inefficiency of updating an entire entity when only a single component has changed. For instance, updating a customer's status should not necessitate updating their other details like name, address, date of birth, preferences, etc., nor should it trigger validation processes for unchanged elements. Hiperspace offers a solution to this extensive update issue by utilizing Aspect for the modified parts. Updating a Customer status aspect does not require changing the entire entity."

Hiperspace uses Horizon to apply CQRS segregation to implement the Versioned pattern. The RBAC example uses CQRS to filter deleted elements but allows an element to be deleted from the current view.

Domain SubSpace

When a .hilang schema model is compiled, a domain SubSpace is generated to provide a repository containing Sets for each of the entities / segments / aspects in the domain. Each SetSpace<> (e..g. ResourceSetSpace) caches elements retrieved from Hiperspace to avoid re-fetch and ensure that every object in a SubSpace is unique.

The name of the domain is defined with the %domain () directive (%domain (Plan); in this example)

In this example PlanSpace is a SubSpace is a Hiperspace. A domain space can be used as the base for a session Spaces in addition to the Hiperspace driver