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.
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.
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.
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 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.
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:
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!