Development Pattern - Extending objects in other modules / components (M5)

2
What's your approach/development pattern to extending an object outside it's original module (or components in Mendix 5)? Do you see other or better options than described here? Or do you see additions to the approaches described? I would be very interested to learn about what your ideas are! As an example, you have a Person object in a PersonAndOrganization module. The application is dealing with, for instance, project management and supports all kind of project management processes. These processes have a demand for all kind of information on Persons and Organizations and the Person object is designed to do just that. Release X of the application a CRM module is added. The idea is to use the existing Person object and extend it with the extra information needed for the CRM processes. This could be done in several ways. Here are the patterns I came up with so far: 1) Add the CRM info to the existing Person object. 2) In the CRM module, create a new CRMPerson object that inherit from the existing Person object. Add the CRM info to the CRMPerson object. 3) In the CRM module, create a new CRMPerson object that has a 1 - 1 association with the existing Person object. Add the CRM info to the CRMPerson object. Thoughts about the different options: Ad 1) Keeping the data together, makes life easier, in lots of circumstances. As long as you have this option, you could take this pattern. However, if you use an external module or component, you might not be able to do that. Especially not if it is Closed Code. Ad 2) Seems straight forward and made sense to me at first. Running into issues with existing Persons, made me abandon this pattern. An existing Person is not a CRMPerson. I believe it is possible to convert the Persons into CRMPersons, but I guess that would require changes in the PersonAndOrganization module. That's not desirable. Think of the external module or Closed Code situation again. Ad 3) 1 -1 relations enable you to extend objects in external modules or Closed Code components. Which is a great plus for this pattern. On the other hand, it forces you to make some custom "plumbing": you have to make your own Save, forms can't be generated for the combination of objects, logic needs to keep in mind that the object info is split over several objects (are the db delete options working as wanted in this approach?). At the moment, I'm using pattern 1 the most. But I expect pattern 3 to be the winning pattern as it enables you to extend external modules and Closed Code components. Which will become crucially important in the Mendix 5 era.
asked
2 answers
0

I have a different solution. Create an entity one to many with an enumeration Persontype. For each selected type I have an inherit. In person there are only those elements that every person has. I can then add to this person a new person type and create for each specialization a new entity with all the needed info.

This way one person object can have many specializations and even on existing persons you can add the new specializations when needed.

Regards.

Ronald

answered
0

I am sure that this question has come up in many Mendix projects and am pretty sure that there are best practices within Mendix on how to handle this kind of componentization. One other option that I understood is to replace cross-module associations with microflows. That is, using microflows as the API to a module. Given the Mx5 release and given that maintainability becomes an increasingly important topic for increasingly larger Mendix models in increasingly larger customers it would be great to have some examples, documentation on which pattern to apply in which situation. Is Mendix working on that?

answered