Data model reuse layers
Designing a data model for reuse is one of the most critical areas in any software project. A well-designed data model has a synergistic effect, the whole being more significant than the sum of its parts. In contrast, a poorly designed data model harms the quality and maintainability of an application.
A temptation exists after a case type is created to define its life cycle immediately. You can rapidly develop case life cycles in App Studio with views that contain numerous properties, everything defined at the case level. This approach becomes counter-productive due to the lack of reusable data classes and work pool-level properties shared with other cases. It takes hours to refactor and retest the code.
It is better to start by grouping related properties using data classes containing the views to display those properties. Creating data classes promotes reuse across an application's case types. Data classes enhance and simplify application maintenance.
One of the primary purposes of a case is to manage a specific set of data. Managing data is a different role than being the data. The primary purpose of data is to be used by one or more cases.
Cases have two types of properties:
|Type of Property||Examples|
|Customer Data||Event Type, Number of Attendees, Cost|
|Transaction State and History||pyStatusWork, pxCreateDateTime|
It is rarely necessary to define new properties for Transaction State and History.
In certain scenarios, you might want to define a case type with little or no life cycle or behavior, to use the case type primarily to store data locally. The case life cycle might consist of changing pyStatusWork from New to Open to Resolved-Completed. It could have a single assignment with a service-level agreement (SLA).
A case may appear simple at first, so you might not feel that it is worth adding a Data Relationship field type. However, a build-for-change best practice is always to associate at least one Data Relationship field type with a case type. Have one of the Data Relationship field types be synonymous with the case type. Doing so helps to avoid scalar properties at the case type.
For example, a Data-Warranty instance that contains static information (such as the terms and conditions of a product's warranty) is read-only. On the other hand, a Data-Warranty-Claim instance contains dynamically varying properties such as PurchaseDate, ClaimDate, ExpirationDate, and Expired. In the view that displays those additional properties, the first two are modifiable. In contrast, the second set of properties are calculated and read-only.
The sample Event Booking application also follows this pattern. The fields within an FSG-Data-Hotel instance are static from an Event case's perspective. In contrast, the fields within a RoomsRequest instance are dynamic.
The data model for a case should also consider the ease with which customer data is propagated from one case to another. A field group can be populated immediately before the creation of a subcase or spin-off case. A field group used this way at minimum needs to be defined at the work pool class level. If the subcase or spin-off case is an extension of a case type component, the applies-to class for the field group needs to be more generic, for example, Work-Cover-.
This Topic is available in the following Module:
Want to help us improve this content?