Abp: Identity module is an example?

Created on 29 Sep 2018  路  2Comments  路  Source: abpframework/abp

Hi hikalkan,
I'm very exciting to see your new achieve. Thank you and your teams' contribution.

There are some questions for the identity module.

  • User, Role, Permission aggregateroot have the fixed primary key( guid ). So if I want to use other data types how to do? (use SnowFlake to generate int64 id)
  • How to extend identity user? I want to achieve ddd's value object, domain event. #406
  • Is this module just an example to show how to use this framework?

Thanks again!

question

Most helpful comment

Hi @Caskia,

Thank you for your interest in the project.

  • ABP is an opinionated framework and we should make some decisions in order to provide ready-to-use solution. GUID selection was one of these. In the current ASP.NET Boilerplate, we have used long as the User PK, however there were many discussions around it. We thought carefully and decided to use GUID. The only way of making it generic it to make it string, but we don't want to do that. So, short answer: No, we can not change it.
  • First of all, we decided to make modules self deployable, has own database (even a module may use Sqlserver, other one use MongoDb in same application) to make them ready to microservice architecture (every module is a candidate for a microservice). So, normally, a module should not extend other module's entity. However, you may want to map your own entity to the same AbpUsers table with another DbContext (if you accept to integrate databases). We will create some documentation describing alternative scenarios. It's a bit early now.
  • No, it's a production ready read module and it's also a best practice model for the framework. You may want to see this to understand our goal.

A short additional info: An application should not inherit from IdentityUser entity. IdentityUser has properties for authentication (like Password, LockoutEndDate... etc) which are not needed by the application. Application's User entity may contain/share some properties like Id, UserName, Name, Surname. In that case, you should create a different User entity with just these properties in addition to your own custom props (don't inherit from IdentityUser). Either share the same physical db table or handle changes via domain events.

All 2 comments

Hi @Caskia,

Thank you for your interest in the project.

  • ABP is an opinionated framework and we should make some decisions in order to provide ready-to-use solution. GUID selection was one of these. In the current ASP.NET Boilerplate, we have used long as the User PK, however there were many discussions around it. We thought carefully and decided to use GUID. The only way of making it generic it to make it string, but we don't want to do that. So, short answer: No, we can not change it.
  • First of all, we decided to make modules self deployable, has own database (even a module may use Sqlserver, other one use MongoDb in same application) to make them ready to microservice architecture (every module is a candidate for a microservice). So, normally, a module should not extend other module's entity. However, you may want to map your own entity to the same AbpUsers table with another DbContext (if you accept to integrate databases). We will create some documentation describing alternative scenarios. It's a bit early now.
  • No, it's a production ready read module and it's also a best practice model for the framework. You may want to see this to understand our goal.

A short additional info: An application should not inherit from IdentityUser entity. IdentityUser has properties for authentication (like Password, LockoutEndDate... etc) which are not needed by the application. Application's User entity may contain/share some properties like Id, UserName, Name, Surname. In that case, you should create a different User entity with just these properties in addition to your own custom props (don't inherit from IdentityUser). Either share the same physical db table or handle changes via domain events.

Ok, Thanks for your instant reply.
If we want to build microservices, may be we need some tools to make sure the final consistency between services.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

SmallShrimp picture SmallShrimp  路  3Comments

vfabregat picture vfabregat  路  3Comments

hikalkan picture hikalkan  路  3Comments

hikalkan picture hikalkan  路  3Comments

ugurozturk picture ugurozturk  路  3Comments