I'm setting up a web application using ASP.NET Core with authentication through Identity Framework. Quick question. I'm storing all kinds of data about the user like their address, account settings, subscription status and expiration date, etc. Am I better to store all that in the AspNetUsers table by creating ApplicationUser class inheriting IdentityUser, or should I keep that table for login/security information and create another table to store data only related to my application, and have a 1-to-1 relationship between the 2 tables?
Always a separate table/class.
Complexity grows with the application. The table will become too large then you would spend time moving away from this. We have similar in our legacy application with an Organisation that has grown to 70+ columns. I've heard stories on Twitter about people with similar experiences.
Also alongside this you can think about Single Responsibility. Given a single reason for change - or more to Uncle Bobs updated definition "A module should be responsible to one, and only one, actor".
You could end up having settings per module - and the more you add, this is just going to get bigger. Sure, just leave it till later to change things - but this never happens.
For me the Identity is its own system. Not your system. It provides a mechanism to authenticate. It uses most columns in the able or fields in the user class to do this.
Your settings is about your application - this is your domain. If you replace Identity, you might replace that user table/user class. Then where will your settings end up?
Collected from the Internet
Please contact [email protected] to delete if infringement.
Comments