Support Multiple Key Types for Base Entity

[iammukeshm]

Guid is a secure and reliable data type. But there can be instances where performance can be a bit down due to lot of Guids in DBs.
To combat this, we can make the BaseEntity to BaseEntity where T can be simple ints as well.

Someone can take this up and raise a PR as well.

Things to note.
Ensure new migrations are built.
Test every other scenario as well.

[AdelSS04]

i think the main problem here is at Repository level :)

[pashaie]

I've tested PR and there is no apparent problem in code behavior.
Please check it out

[pashaie]

I've done some work to support generic Key type in this project, but imho the result wasn't good.
the repo methods needs to be changed to accept TKey and client code must provide TKey type in everywhere because C# Method type inference ignores generic constraints on the method type parameters
Other solution that I was considering was to provide multiple RepositoryAsync for example RepositoryIntAsync or RepositoryGuidAsync , but that would be massive code duplicate and also bypassing UOW

So I'm wondering if anyone has a better idea?
btw we can also consider ULID instead of GUID for primary keys:

Universally Unique Lexicographically Sortable Identifier

A GUID/UUID can be suboptimal for many use-cases because:

• It isn't the most character efficient way of encoding 128 bits
• It provides no other information than randomness

A ULID however:

• Is compatible with UUID/GUID's
• 1.21e+24 unique ULIDs per millisecond (1,208,925,819,614,629,174,706,176 to be exact)
• Lexicographically sortable
• Canonically encoded as a 26 character string, as opposed to the 36 character UUID
• Uses Crockford's base32 for better efficiency and readability (5 bits per character)
• Case insensitive
• No special characters (URL safe)

[iammukeshm]

https://github.com/blazorhero/CleanArchitecture/blob/master/src/Domain/Entities/Catalog/Brand.cs

We have developed more or less the same requirement for BlazorHero as well. Can you please check it.

[pashaie]

@iammukeshm thanks.
the problem arise in RepositoryAsync:

• equality checks like e.Id == entityId will cause Operator '==' cannot be applied to operands of type 'TKey' and 'TKey' because of TKey is not constrained. we can constrain TKey with where TKey : struct but string and/or guid are not struct and int is not class. the solution that I'm considering is to provide overloaded method for type int and guid. but that's tricky.
• methods like GetByIdAsync<T> needs to be changed to GetByIdAsync<T, TKey> and client code needs to supply each of this types. for example code like GetByIdAsync(product) needs to be changed to GetByIdAsync<Product, Guid>(product)

[imnikitaokunev]

• equality checks like e.Id == entityId will cause Operator '==' cannot be applied to operands of type 'TKey' and 'TKey'
  Can we use Equals() method instead of == operator?

[pashaie]

@iammukeshm I'm not quite sure. because predicate will be translated to sql, I suspect that Equals can't be translated.
can you check it out?

[pashaie]

@imnikitaokunev Equals() works, tnx!