Best Practices User Wrapper

  

I assume many people use user wrapper classes in their applications to extend the user entity with more program specific information.

I was wondering what the best practice would then be referring to those users in the programs context.

For example:  

In a School application, you create a Student entity wrapping User with UserId as its Id with additional information like Teacher, and Grade level.

Then when you create an Assignment entity that you want to associate with the Student, should you point to the Student Identifier or back to the original User Identifier. 

Though they are the same in execution, they change the behavior inside of the platform. For example, when creating Entity Diagrams, the line will point to either the user or the student.

What do most people do when creating User wrappers? What is the best practice?

Hi Jordan,

The best practice is like you said, extending the Users entity: https://success.outsystems.com/Documentation/Development_FAQs/How_to_add_additional_logic_to_users_login

If you want to check some examples, you can search for sample apps on Forge. Check this for example:

https://www.outsystems.com/forge/component/937/employee-onboarding/

cheers,

Vera

Solution

Hi Jordan,

I think in the case you mentioned, your Assignment entity should point to the Student Identifier. 

Even though a Student is a User (one-to-one relationship), a User might not be a Student, therefore if you pointed to the User identifer in you Assignment entity you wouldn't have a foreign key constraint that limited you adding an Assignment to a Student.

They are very similar, but not the same in execution, by adding Student Id to the Assignment you are preventing adding Assignments to Users that are not Students. if you tried, you would get an error like:

The INSERT statement conflicted with the FOREIGN KEY constraint "Student_ID". The conflict occurred in database "outsystems", table "dbo.ASSIGNMENT", column StudentId'. The statement has been terminated.

On the other hand, if you pointed to the User Id, the above error would not occur, but your data model would not be as logically consistent.

Cheers,

João

Solution

João Mateus wrote:

Hi Jordan,

I think in the case you mentioned, your Assignment entity should point to the Student Identifier. 

Even though a Student is a User (one-to-one relationship), a User might not be a Student, therefore if you pointed to the User identifer in you Assignment entity you wouldn't have a foreign key constraint that limited you adding an Assignment to a Student.

They are very similar, but not the same in execution, by adding Student Id to the Assignment you are preventing adding Assignments to Users that are not Students. if you tried, you would get an error like:

The INSERT statement conflicted with the FOREIGN KEY constraint "Student_ID". The conflict occurred in database "outsystems", table "dbo.ASSIGNMENT", column StudentId'. The statement has been terminated.

On the other hand, if you pointed to the User Id, the above error would not occur, but your data model would not be as logically consistent.

Cheers,

João

Thanks João, that is what I was thinking. Because then theoretically if you had another "Teacher" entity that extended user as well, you could use this method to prevent mixing up the two while assigning them.  While writing the scenario I sort of answered my own question, but wanted to hear some other input of what people are doing.