Many to many association in offline-first scenario - Experience sharing and concrete examples about workarounds
Hi everyone, I’m looking for advice about how to proceed with mendix in a specific situation. If anyone met issues similar to what I describe below, would you be so kind as to share insights and maximum details about the solutions that where implemented ? Would be nice for mendix newbies such as me to be able to get a global picture about this without having to spend weeks falling into the same traps a lot of people may have handled before :) I’ve been looking in vain for any article helping me on that. I’m fairly new to mendix and currently doing a POC to see if we can rewrite most of our entreprise internal productivity tools using mendix. The first contacts with the studio are very encouraging with some exceptions... In short I need to write a web app + mobile first application using the same domain model. The first obstacle I’m meeting is the use of many to many (reference set) in offline mode. That seems to be a classic as I found some questions about that : https://community.mendix.com/link/questions/108843 https://community.mendix.com/link/questions/107493 https://community.mendix.com/link/questions/91335 https://community.mendix.com/link/questions/88421 I perfectly get the principle of the workaround that is always proposed : Replacing many-to-many assocations between two entities by a third entity with two one-to-many associations. As an experienced developer I understand that the underlying representation would be quite close between those two patterns. What I wonder though is the impact on the development flow. It raises a few questions for me : How does that impact the (marvelous) options the studio provides for generating overview pages and such ? Is it still possible to provide a fluent UX with that workaround ? The use of the reference set selector input is an example of that fluent UX What are the impact on performances ? Those are just the first questions that come to mind but that rabbit hole seems deep to me… My first thoughts about how to approach this would be either : Keep creating a domain model with many-to-many associations when relevant (And it’s so very often relevant) Create a “shadow” domain model for offline mode, with “in between entities” implementing one-to-many associations Create the necessary microflows linked to the relevant events to keep the shadow in sync with the “master” That solution looks like the perfect “Wrong good idea” as it introduces a lot of maintenance pitfall where a lot can be let behind when making the main model evolve… Every time I can anticipate that an association may be used offline, implement the workaround in the domain model But what if the needs evolve later and an association unexpectedly enters that scope... Never use many-to-many associations in any model and get used to the workaround and its own potential limitations from the start. Seems a shame to potentially sacrifice some mendix advantages “Just in case” So now you got it, I’m mainly reaching to experienced Mendix people to help me start this project on the right tracks :) Cheers, Sylvain
I will try to answer your questions based on a previous project of mine which was a native mobile offline app.
For making offline work in your Mendix app you will need to work a little harder and different than used to in a responsive app. But this is mostly in the model area and object synchronization where there are some restrictions. Generation pages for responsive and mobile will work fine mostly.
Things like reference set selectors usually have quite a different styling in mobile than in responsive. These, like other ‘selection’ pages usually have to be modeled out with microflows and listviews to make them work nice and without pop-ups.
The performance drawback depends on your end solution. In our case, we had the *->* relations for responsive and reporting and made use of extra 1-* relations for mobile. In event handlers on the entities used, we kept the model in sync are created the extra needed objects or set the proper associations, based on the source of the change (responsive or mobile). The impact was minimal and not noticeable to end-users.
All in all, I think you're on the right track. What was/is a drawback for most of us, that we're used to modeling for responsive and then had to ‘learn’ how to model for mobile, maybe won't be an issue for you because everything will be new.