Support Multiple Key Types for Base Entity about dotnet-webapi-boilerplate HOT 8 CLOSED

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)

from dotnet-webapi-boilerplate.

@imnikitaokunev Equals() works, tnx!

from dotnet-webapi-boilerplate.

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

from dotnet-webapi-boilerplate.

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

from dotnet-webapi-boilerplate.

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.

from dotnet-webapi-boilerplate.

@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)

from dotnet-webapi-boilerplate.

• 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?

from dotnet-webapi-boilerplate.

@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?

from dotnet-webapi-boilerplate.