Separation of Identity Bank from Application

Asked

Viewed 234 times

0

When using Asp.net Identity, a single bank is generated. And it is recommended to leave this bank only for Identity and create another bank for your application, as I read in some articles.

So far so good... Then I went to see a video lesson (link in the last line) of Eduardo Pires where he creates an User entity in the domain of the application with the same data of the table "Aspnetusers", and in the repository he points to the Identity database and maps the User entity to the table "Aspnetusers" and with that, I can move the Identity User table as if it were in my system database.

And my doubt arises from there:

In my application I must also have a User, but with data related to the business (CPF, City, Products List, Otherside, etc), in addition to the data already contained in the table Aspnetusers. But I cannot point this User to the Identity database, because then it would already be mixing tables from the application database with the Identity database. However I need the Identity table to do the User control. How can I do this separation?

Link to the video lesson: https://www.youtube.com/watch?v=GGPANv47Z3k (from the minute 30:20)

Project at Github: https://github.com/EduardoPires/IdentityIsolation/tree/master/src

  • 6

    Why "[...] it is recommended to leave this bank only for Identity and create another bank for your application"?

  • 7

    I agree with the point of @jbueno. What would be the reason? Bank is bank. Use of entities will depend exclusively on your model.

  • 6

    This recommendation of separation doesn’t make any sense, so much so that there is this package that integrates Identity with the Entity Framework. This video classroom is a collection of bad practices.

  • So I can add data, relationships in Aspnetusers and other Identity tables without any problem? Because I thought it was strange to have two banks for a single application.

  • 2

    It doesn’t have to be two banks, you can put it all in one database alone, I think it’s even easier to work like this.

  • 'Cause it’s Ricardo, I think, but since I’m a beginner I’m still a little confused. I’ll work with a bank.

  • 2

    I use Identity in my external bank without any problem.... and detail, customized. The cool version 2.x is precisely for having more flexibility.

Show 2 more comments

1 answer

3


Just from the point of view of object orientation, avoid using inheritance in this case, use aggregation. What you are calling Usuario in your business model is not a user, is a Pessoa (or another name you prefer to use), which has a user that allows you to access the system with some paper. Because this person has CPF and data that in principle do not belong to a class Usuario. This yes has data related to identity and authorization, such as "login", "password", "papers", etc.

An entity that represents a person within its system (which could be even a legal entity with CNPJ) should only "reference" a User of the Aspnetidentity tables. This reference may (or should) be weak, keeping only the user id, for example, if you want to keep the banks separate (it would not be possible to maintain referential integrity even).

Taking further, the same user can be "used" by more than one person. In several systems I write there are users who allow access to different people simultaneously (the user chooses which "person" will use after logon). This allows an accountant, for example, to log in to several clients, without having to remember different passwords and logins for each one. But only add this complexity if your business model requires it.

The suggestion to keep the user database separate is because you may have users who connect from other identity providers such as Google and Facebook. Trying to maintain an almost total separation between the "access" control to your system and the system itself is very interesting. In addition, it allows other systems to use the same user database, without necessarily using the same database as the system itself.

My suggestion is to put the database with the table Aspnetusers in the same database of your application, because this simplifies things, mainly for beginners, but would avoid at all costs to create dependencies between the tables/ business objects and the tables of users. As I said, save the user ID when you need this reference, without creating a Foreign Key (integrity reference) between tables.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.