Question

Administration.Account: inheritance or (1-1?) association?

2

Hey, 1) What are the pro's and cons of inheriting vs associating (your app-users) to Administrator.Account? 2) Same question for System.User (vs Administrator.Account)? Bonus: 3) Why is Account a separate entity from User? Why not just have placed those three attributes under User (and then associating that with [Account]PasswordData? Is it to accomodate the option of one user having multiple accounts? (Or... one account having multiple users -- or some other association?) Regards, Joris

asked 2017-11-13

Joris Hehenkamp

3 answers

🚴René van Hofwegen🎓 · Answer 1 · 2017-11-14

Corne's explanation on why account is inherited and not part of the System.User, is correct. The System module is hardcoded and thus cannot be altered. While you might want to extend the information and stored about an account (User) The administration module is a basic (but nifty) implementation of account handling.

Let me shed a light on the discussion Ronald was mentioning;

User data is restricted to the user itself [id = '[%CurrentUser%]'] So data can only be accessed by the user itself (and the admin). So when inheriting from User (account) you say, that the person in the process (i.e. the employee or customer in an ordering app) equals the fact that he/she can login to the application. This is NOT true and will conflict with the access restriction. An Employee (or customer) HAS an account which is of course related (1-1) to the employee entity. by using a 1-1 association, you can still determine who is logged in to the app, but the account data is not part of the process. Also, using a 1-1 association allows you to not have an account for certain person in you app. in the mentioned example, customers might not have an account, but are administrated from the back-office side.

I have heard from sources @mendix that there will be an new advanced learning path discussing the topic Advanced Domain Modeling. My gut feeling says that this discussion will be part of it ;-)

Corné Hoogendoorn · Answer 2 · 2017-11-13

Hi Joris,

Mendix has some great documentation regarding these topics available. I think the following link describes very well the pro's and cons of using one or another, you can take the best pic for your situation:

https://docs.mendix.com/howtogeneral/bestpractices/inheritance-vs.-1-1-association

About Account and user, as you can see the user entity is in the fixed System module of Mendix itself. It's the core of your application and cannot be touched therefor. You could suffice without the administration module but it comes with some out of the box functionality such as changing password which I mentioned to you earlier but also other functions which makes our life a little bit easier when setting up a Mendix project.

Regards

Ronald Catersels · Answer 3 · 2017-11-13

It is a pity I can not find the discussion I had on the forum with Rene van Hofwegen who has been from a long time doing the classroom instructions on Mendix. The discussion was if a user has an account or is an account. I do not know the current state of affairs and the link to the documentation gives a nuanced view on this but the classroom would say to use a 1 on 1 relation with account (and let account inherit from the user). So the classroom opinion was that a user has an account and not that the user is an account. But I like the nuanced view of the documentation. It's a pity I can not find the old discussion about this topic because I do seem to recall that there was also a securty viewpoint that would favor the has account above is account but I cannot remember the reason anymore.

Regards,

Ronald