Separation of the Identity Bank with the Application [closed]

Question

Separation of the Identity Bank with the Application [closed]

Navigation

#1 by (3 votes)

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 ... I went to see a video lesson (link in the last line) of Eduardo Pires where he creates a User entity in the application domain with the same data as the table "AspNetUsers", and in the repository it points to the Identity database and maps the User entity to the "AspNetUsers" table, and I can move the Identity User table as if it were in my system bank.

And my question comes from this:

In my application I must also have a User, but with data related to the business (CPF, City, Product List, Other entity, etc.), in addition to the data already contained in the AspNetUsers table. But I can not point this user to the Identity database, since I would already be mixing tables from the application bank with the Identity database. However I need the Identity table to control the User. How can I make this separation?

Video lesson link: link (from 30:20 minutes)

Project on Github: link

c# ddd asp.net-identity

asked by anonymous 14.10.2016 / 22:44

1 answer

Error picking the selected item in a Spinner and showing in a Toast execute Task.When all wait and then go back run

score 3 · Accepted Answer

Only 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, it 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 does not belong to a Usuario class. This yes, it has data related to identity and authorization, such as "login", "password", "papers", etc.

An entity that represents a person within your system (who could even be a legal entity with CNPJ) should only "refer" a User to the AspNetIdentity tables. This reference can (or should) be weak, saving only the user ID, for example, if you want to keep the databases separate (you could not maintain the same referential integrity).

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

The suggestion to keep the users database separate is because you might have users connecting from other identity providers like Google and Facebook. Trying to maintain an almost total separation between "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 system database itself.

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