Component Based Development

Hi all, As most of us know, Component Based Development is a relevant topic when developing (larger) applications with Mendix, especially in a multi-app landscape. The Mendix best practices offer a series of tips & tricks and when to (or when not to) apply CBD. However, I am sure there are many more hidden gems concerning this topic in the Mendix community. For example, Mendix recommends to avoid cross-module associations and use keys instead, when connecting to a module in a CBD scenario. However, the use of keys, in some ways, goes against all we learn as Mendix developers - I've spent many a day convincing others to drop legacy keys and think in associations instead. Furthermore, it's easy enough to display data grids via associations or database retrieves, but it becomes another thing entirely if your retrieve can only be done via comparison of two keys, and no other associations between the objects. You would likely have to use microflow data sources for your data grids, which is limiting in other ways (no search options etc.). What, according to the community, are some ways of applying CBD across modules whilst still adhering to the 'spirit of Mendix' in terms of references and associations? How does a module truly become "stand alone" yet at the same time retain its flexibility and usefulness given the advantages of the Mendix platform? Thanks for your input!
1 answers

Hello Querijn,

I'm not a subject expert on this matter, but I'm interested in the subject too. For me the most important question is why people decide to apply Component-Based Development i.e. for maintainability or distributed development etc. It would be really nice to discuss some real-life use cases during a Mendix meetup. Would really like to know their arguments and lessons learned etc. 

Are there any volunteers to show their CBD implementaion during a Mendix meetup?