The “Many and Primary” Design Pattern

Design patterns are essentially an optimal, “best practice” solution to a common problem. Typically design patterns solve computer code related problems but Mendix is transforming the traditional world of building systems in that the platform promotes a greater than ever focus on business problems. Design patterns within the Mendix world therefore create reusable solutions to common business related scenarios.

One such design pattern is the “Many and Primary” design pattern. In the business world we often find a relationship between business entities whereby one entity will be linked to many other entities but one of those entities will be a selected primary. One example of this is a very South African specific example whereby a user might speak more than one of the countries 11 official language but have a preferable home language (a primary language). From a solutions point of view the Business Engineer needs to find a way to both link to more than one language but also efficiently highlight the users primary or preferred language. The “Many and Primary” design pattern solves this problem in 3 ways:

1. The Entity Model

The first step is describing the solution within the entity model. The essence of the design pattern is described in the two associations linking the two entities. Firstly we have a 1:1 relationship describing the primary language of a person (the primary relationship), secondly we have a 1:many relationship linking any other languages the person might speak.

Example of the entity model for the Many and Primary design pattern

2. The Capture Screens and Supporting Microflows

On the capture screen a user will be required to select a primary language – implementing this feature is most easily done via a drop down list and then the secondary languages via a search data grid.

A screen indicating how the user would interact with the “Many and Primary” design pattern

Languages are then finally added to the person via a Microflow labelled, in the example case above, as “Select Language”. The Microflow is designed to do 3 things:

1. Check that the language hasn’t been added before

2. Check that the language marked to be added hasn’t been added as a primary language thereby avoiding a situation where an entity is selected as both primary and part of the many list

3. Link the selected language to the user via a change activity.

The Microflow used to link languages to the user

3. The Retrieve List Microflow

Now that we’ve constructed a way to save the data in a pattern we need to ensure that the data can be retrieved consistently as well. Since the primary language as well as the other spoken languages of the user should essentially form a single list: All languages spoken by the user. A simple retrieve won’t give that to us because the primary language isn’t saved as part of the other languages. Therefore we implement a retrieve Micrflow which retrieves the list of languages spoken by the user, adds the primary language to that list and then finally returns the list of total languages spoken by the user.

The microflow to retrieve list of attached languages to a person

The design pattern can be used against many business type problems – for example if a user has many cars but has one they drive most often or a family on medical aid but have a primary member etc.

By thinking in design patterns we can both stream line solutions making it easier for other modellers to understand the solution as well as accelerate project implementations by identifying common problems that can be solved in a common way.

UPDATE

After the post Pieter van de Braak made an interesting comment that made me realize a flaw in entity design.  It has now been updated to the following:

The entity model for the mendix primary and many design pattern

Falling victim to a “lab case” in the first entity model it essentially prevented scalability. The update essentially means that the languages in the language entity can be re-used. A big thanks to Pieter for picking that up!

Get Create – A solution to the dilemma of using Entities in quantum states.

A common problem I come across in developing Mendix applications is when I have to manipulate an entity in a microflow which may or may not exist. This quantum  occurance would occur when having to update an entity from a 1-1 relationship, or on a 1-* where the child entity (on the many relationship side of things) is also related to a secondary attribute, such as a day or version.

When dealing with this situation you have to try retrieve the entity using the relationship or Key Attribute(such as date), check if it exists, if it doesn’t  create the entity with the new Key Attributes. This now leaves us with two  entities which have to be manipulated seperately or reretrieve the entity into  a common name.

Going with the first case lets look at what my first pass solution would look like on the following Module:

As can be followed from the above microflow there will be much duplication of logic, and complication of the microflow at quick inspection.

Note: When checking to see whether an entity I retrieved exists I like to create an exclusive split with the caption ‘Exists?’ and the formula ‘not($Entity=empty)’. This keeps the reading of the flow in the positive light rather than negative.

The solution I follow now as my standard practice in these circumstances is to create a microflow called Entity_GetCreate which will handle this retrieve or create logic for me and return the respective entity so that I dont need to concern myself with handling these cases seperately.

This GetCreate microflow for the above entity would look as follows:

Which results in the original microflow being simplified to:

Much easier to read for business and mendix users.