(ASP.NET MVC 5, EF6, VS2013)

Próbuję wymyślić, jak to zrobićzmień typ pola „Id” z łańcucha na int w typie:

Microsoft.AspNet.Identity.EntityFramework.IdentityUser

aby nowe konta użytkowników były powiązane z identyfikatorem całkowitym, a nie identyfikatorem GUID. Ale wydaje się, że będzie to bardziej skomplikowane niż dodanie nowej właściwości Id z typem int w mojej pochodnej klasie użytkownika. Spójrz na podpis tej metody:

(z Assembly Microsoft.AspNet.Identity.Core.dll)

public class UserManager<TUser> : IDisposable where TUser : global::Microsoft.AspNet.Identity.IUser
  {
  ...
  public virtual Task<IdentityResult> AddLoginAsync(string userId, UserLoginInfo login);
  ...
  }

Wydaje się więc, że istnieją inne metody upieczone w strukturze tożsamości ASP.NET, które wymagają, aby userId był ciągiem znaków. Czy musiałbym ponownie zaimplementować te klasy?

Wyjaśnienie, dlaczego nie chcę przechowywać identyfikatorów GUID dla identyfikatorów w tabeli użytkowników:

- Będą inne tabele, które wiążą dane z tabelą użytkowników za pomocą klucza obcego. (Gdy użytkownicy zapisują zawartość na stronie.) Nie widzę powodu, aby używać większego typu pola i wydawać dodatkową przestrzeń bazy danych bez wyraźnych korzyści. (Wiem, że istnieją inne posty na temat używania identyfikatorów GUID vs int ids, ale wygląda na to, że wielu sugeruje, że int ids są szybsze i zużywają mniej miejsca, co wciąż mnie zastanawia.)

- Planuję ujawnić spokojny punkt końcowy, aby umożliwić użytkownikom pobieranie danych o konkretnym użytkowniku. Myślę:

/users/123/name

jest czystszy niż

/users/{af54c891-69ba-4ddf-8cb6-00d368e58d77}/name

Czy ktoś wie, dlaczego zespół ASP.NET zdecydował się na wdrożenie ID w ten sposób? Czy jestem krótkowzroczny w próbie zmiany tego na typ int? (Być może brakuje mi korzyści.)

Dzięki...

-Ben