Why is it a best practice to avoid inheriting from Administration.Account—even though its used in Mendix courses?

0
Hi everyone, I’ve read in Mendix best practices that entities should not inherit from Administration.Account, but I’ve also noticed that in several official Mendix learning paths and courses, example Mendix Academy - Create an App with Advanced Page Building, they actually do use inheritance from Administration.Account. This seems contradictory, so I’d really appreciate some clarification: Why is inheritance from Administration.Account discouraged in practice? What are the downsides (e.g., technical, security, performance)? If courses use it, are there specific scenarios where it's acceptable? Would love to hear your thoughts or any official guidance on this.   Thanks in advance!
asked
2 answers
2

A user has an account not is an account. And indeed this has been a long discussion. But let's take the Mendix community as example. When I am a consultant you could end up with multiple accounts in the Mendix environment. But in the ideal world you would have one account with multiple different identities and you could switch identity. This way all your forum points would end up in your one account while security checks your identities instead of your account. 

With inheritence you would not be able to do this. So from an architecture standpoint use the reference instead of the inheritence.

Regards,

Ronald

 

answered
1

Hi there,

 

Your question touches quite a few points, so I'll give my thoughts - just remember that best practices is not rules set in stone. At times, you might need to implement something against best practice due to your requirements.

 

Inheritance vs. Association

In Object Oriented Programming, the use of using inheritance or association can cause some debate. I've seen Mendix developers shying away from the use of inheritance and other fully embracing it (and creating powerful solutions with it). The crucial question you need to ask yourself is: "Is this entity a {insert other entity name} or does it have a {insert other entity name}". If it is, use inheritance; if it has, use association

 

Using Marketplace-Related Content

At times you require some bespoke handling. A mistake that a lot of beginners make is to amend the Marketplace module. The issue with that is when you upgrade your Marketplace module, you lose all your changes that you made in that module.

That said, the Administration module is quite stable, but let's assume you've extended the Account-entity and added an attribute Gender. Should a new version of Administration be released with the same attribute, and you chose to update it, it can cause conflicts.

 

Security

Depending on your needs, you may need to apply special security for your entity. The Administration module provides a great basic foundation. Again, here you can go either way - inherit or associate. Keep in mind when you inherit, your specialization's access rules will govern your user access. You may still need to maintain security for your generalization if it is exposed somewhere.

 

Other Best Practice and General Considerations

Generally, you don't want to inherit more than 2 times. Hence, creating an inheritance from Account is already your second inheritance

Using inheritance, allows you to reuse some functionality applicable for the generalization

In microflows, you have access to your current user's User-entity. If you require information from the specialization, you either need to cast it or retrieve it.

 

I believe both has their place. "When in doubt, use the safe route out", which is associate. This is especially true for large, complex and/or long-term applications. If you want to add a single field, I will say inheritance is fine.

answered