Page History
...
| Table of Contents | ||
|---|---|---|
|
| UI Text Box | ||
|---|---|---|
| ||
| Experienced Business engineers might use the Dossier Manager (Dossier plugin) for Persistency Management. The functionality described in this design guide is aimed to replace this Dossier Manager. |
...
When storing such an aggregate, metadata is stored as well. This includes standard metadata, such as when the aggregate has been created and who created it, but also custom metadata that the business engineer can define on the aggregate definition by using expressions. This custom metadata can be seen as identifying attributes for an aggregate, but are not necessarily unique. In the example above, the Person aggregate could have the following custom metadata attributes: FirstName, LastName, SocialSecurityNumber, CurrentJob, HouseholdSize. As you see, custom metadata for an aggregate can originate from different entities, or even be a complex expressions, for example NumberOfJobs is calculated as COUNT(COLLECT Job FROM Person.HasJobs)
| UI Text Box | ||
|---|---|---|
| ||
| It is even possible to define custom metadata that does not originate from entities of the aggregate definition at all, since custom metadata consists of an expression. This is not advisable in general, as there is no guarantee that the information needed to fill this attribute is available when reading and updated an aggregate entry at a later point in time. |
Only the (custom) metadata is available in lists, as this information is stored in an efficient manner. When a new aggregate entry is created or updated, the (custom) metadata is updated as well.
| UI Text Box | ||
|---|---|---|
| ||
Please think carefully about the choices for your metadata attributes. If you at a later point in time want to add a different metadata attribute, it will be empty for all existing aggregate entries. Once such an existing entry is updated, the new metadata field is going to be filled. |
...
- Aggregate create service: AQ_Aggregate_Create
- Aggregate read service: AQ_Aggregate_Read
- Aggregate update service: AQ_Aggregate_Update
- Aggregate delete service: AQ_Aggregate_Delete
| UI Text Box | ||
|---|---|---|
| ||
With the (deprecated) dossier manager it is possible to clear the profile with one service call (init). Persistency management functionality does not provide such a service, since such a service is not part of persistency management but instance management. |
...
- No versioning
Updating an aggregate instance means that the original aggregate instance is overwritten. There is always one single version of the aggregate in the database present. Reading a non-versioned aggregate instance is trivial: it will read "the" aggregate instance, since there is only one. You should use this strategy if the past state of the aggregate is not important. - Versioning all
Updating an aggregate instance means that a new version of the instance is stored alongside all previous versions. When deleting such a versioned aggregate instance, it is necessary to specify which specific version(s) to delete. Reading an aggregate instance also means that it has to be specified which specific version(s) to read.
Beware that the number of versions for an aggregate instance can grow out of control with this strategy. Also, think about the design of your aggregate list when using full versioning. You should use this strategy if it is important what the state of the aggregate in the past was. For example the employment status of a customer at the moment of the start of the application. Any changes during the processing of the application should not be considered. - Versioning latest
This strategy is based on the previous strategy, but with some limitations for the end user. Versioning is still in place, so updating an aggregate instance will create a new version of the instance, but in this strategy reading will always return the latest aggregate instance version. Deleting an aggregate instance with this strategy means deleting all versions. Also be aware of the fact that the number of versions for an aggregate instance can grow out of control. You should use this strategy if you always want to work with the latest version, but you still want to keep a history of the aggregate. A good example is the address of a customer. You always want to use the newest address for correspondence, but keeping the old addresses may be useful.
| UI Text Box | ||
|---|---|---|
| ||
These strategies are not enforced, and it is up to the Business Engineer to choose one and follow it during modeling. The Business Engineer has all the freedom to choose the correct action for every situation. |
...
In many situations you want that different aggregate entries refer to another. For example should the case aggregate refer to the person that this case is about.
| UI Text Box | ||
|---|---|---|
| ||
| We assume that there is no relation between the case entity and the Person entity as the Person would be stored together with the case if this is the case. |
...
Overview
Content Tools