Recent site activity

OS Projects‎ > ‎CRUD Applications‎ > ‎

CRUD Commands

Purpose

Modern client-server applications manipulate complex graphs of data objects. For example an insurance contract with its positions and optional amendments is represented as a hierarchy of data. These information graphs are transferred between the server and the client applications. The user views data, edits it and commits the changes to the server and the underlying database through server functions. The patterns commonly found in the literature describe thoroughly how to implement simple data transfer objects DTO but ignore the complexity how graphs of objects should efficiently be transmitted between server and client components. 

The intended audience is software developers interested in using Data Object Graphs or implementing their own variant. The framework described provides pragmatic solutions to this common problem. This “state of the industry” approach efficiently transfers trees and graphs of value objects between client and server. Modern code generation technologies, based on the model driven architecture MDA approach are used to generate needed code artifacts. The application architect can fully concentrate on the business analysis and avoid loosing time to solve infrastructure problems.

The approach used in this implementation is to transmit all operations performed on the graph of entities to the server for execution. Therefore no complex logic to find out which changes were performed on a graph needs to be implemented. The changes are send as a list of commands to execute on the original graph of entities. This approach is different to previous designs we publish in the pmMDA project where the commands were computed as the differences between two graphs of objects.

Commands

Manipulation on a graph of entities can be described with the following commands.
  1. Create entity([external identifier]): Creates a new entity in the local session context. The optional external identifier should be set. The internal identifier is set to a negative value unique in the session, the version is set to a negative value.
  2. Delete entity(internal identifier): Deletes an entity in the local session context. If the entity is a local one, meaning the internal identifier is negative, the entity is dropped.
  3. Change entity(internal identifier, version, property, old value, new value): Updates a property value of the entity.
  4. Add entity to(internal identifier of child, internal identifier of owner, version of owner): Adds an entity on a relation of an existing entity.
  5. Remove entity from(internal identifier of child, internal identifier of owner, version of owner): Removes an entity from a relation of an existing entity.
  6. Move entity: The operation is a composite one. The first step is to execute a "remove entity from" and then an "add entity to" with the same child entity. The semantical dependency is hold in the composite command.
  7. Bulk change entity: The operation is a composite one. Multiple "change entity" on the same instance are performed. A bulk of modified properties on the same instance are collected in one composite command.
Each entity has four characteristics
  1. Qualified classname: The name defines the type of the entity. Aliasing can be used to have more compact and readable names.
  2. Internal identifier: The unique value identifying an entity of a given type. The value is managed through the system. Negative values are used for local instances, positive values are used for system wide objects. The internal identifier is only visible in the system, the user or external systems have no awareness of its existence.
  3. External identifier: An optional value identifying an entity of a given type. The uniqueness is the responsibility of the user or external systems. The external identifier is visible to the users and external systems.
  4. Version: The version identifies a revision of a specific entity. This value is used to discover simultaneous changes from multiple users on the same entity.
The qualified classname and either the internal identifier or external identifier uniquely identify an active instance in the context of a domain model. In other words these two information always find the row of data in the relational database.

Adding the version empowers you to retrieve the archived instance in the context of a domain model and its lifecycle.

Storing the commands in a queue command provides an efficient implementation of undo and redo behavior on the domain model.

Design

To be written
Comments