Hej!
Od razu zaznaczę, że projekt jest robiony trochę dla zabawy, trochę do portfolio, także zapewne użycie IdentityServera jest overkillem, ale chcę zwyczajnie zrobić coś ciekawego, szczególnie, że z samym IdentityServerem wcześniej się nie bawiłem i jest to doskonała okazja.
Moje pytania rodzą się tylko z tego, że sam zawodowo pracuję jako .net dev, ale do tej pory w pracy korzystałem tylko z nierelacyjnych baz (wiem, dosyć wyjątkowo) stąd brakuje mi takiego doświadczenia z bardziej zaawansowanymi rzeczami w budowaniu relacyjnych baz.
Chcę stworzyć aplikację, upraszczając całość, chciałbym aby trzymać userów w IdentityServerze, tak aby mieć osobną aplikację do autoryzacji, a cała reszta byłaby obsługiwana przez drugię API .net + EntityFramework.
I teraz tak, na potrzeby tego tematu załóżmy, że mamy tylko 3 encje, kolejno są to User, Company oraz Truck. User powinien mieć przypisaną firmę (choć jak tak teraz myślę, to bardziej encja Company powinna mieć przypisanego Usera, ale już mniejsza o to, problem będzie ten sam), a User z odpowiednią rolą będzie miał przypisaną ciężarówkę. Problem pojawia się przy okazji mapowania zależności w relacyjnej bazie, no bo popatrzcie, jeżeli autoryzację chcę obsłużyć przez IdentityServer, wypadałoby trzymać dane dla tej appki w osobnej bazie, niż cała reszta aplikacji. Spoko, z tym nie mam problemu, ale schody pojawiają się wtedy, kiedy próbuję rozkminić jak sensownie połączyć usera z bazy od IdentityServer z resztą bazy, bo jednak po stronie UI zarówno User'zy jak i reszta encji powinna być w założeniu możliwa do przeszukiwania z odpowiednimi filtrami, pobierania danych itd. itp. Pojawiło mi się jednak kilka pomysłów, poniżej wypiszę je wraz z plusami oraz minusami, jakie są moim zdaniem:
Mapowanie usera w tabelach bazy zawierającej pozostałe encje (np. truck):
- zaburzenie logiki - w takim zestawieniu to ciężarówka będzie posiadać użytkownika, a nie na odwrót
- brak tworzenia osobnych tabel (jeśli można to nazwać plusem)
- brak mapowania zależności w bazie idenitty (co wydaje mi się być ogólnie złym pomysłem, wydaje mi się, że identittyserver nie powinno mieć dostępu do danych, które są istotne dla drugiej części aplikacji)
Mapowanie encji Truck z Userem w bazie Identity
- Konieczność wołania IdentityServera w przypadku przypisywania ciężarówki, czy potencjalnie odwoływania się do dwóch tabel na raz w przypadku pobrania jakichś wartości
- Wrzucanie id'ków do encji z innej bazy danych do bazy Identity
- Bardziej logiczne miejsce przypisania w tym wypadku Truck'a do User'a
Stworzenie tabeli mapującej zależności z obu tabel
- dodatkowa tabela, tylko do mapowania
- problem przy sortowaniu / filtrowaniu danych
-
brak potrzeby wołania dwóch baz w przypadku większości operacji
Pojawił mi się też kolejny pomysł, czyli duplikacja danych dla Usera, czyli trzymanie w tabeli User w bazie Identity wszelkich informacji potrzebnych do autentykacji użytkownika, a w tabeli User, w bazie z resztą encji kopii potrzebnych danych, do po prostu samej logiki aplikacji, jak różne relacje z innymi obiektami itd., co z pewnością rozwiązałoby sporo problemów, ale zapewne za nimi pojawiłyby się kolejne.Pytanie brzmi - jak to wygląda z punktu widzenia prawdziwej, realnej aplikacji biznesowej, gdzie jest osobny IdentityServer + API postawione za nim? Jak to jest logicznie podzielone, tak aby użytkownik mógł być nie tylko encją w identity do autentykacji, ale również mógł spełniać wymogi biznesowe? Strasznie mnie to ciekawi i chciałbym rozwiązać ten problem, ale chciałbym posłuchać co mają do powiedzenia osoby, co robiły kiedyś coś podobnego.
W ostateczności wywalę pomysł używania IdentityServera, ale chciałbym jednak na nim bazować z uwagi na to, co on oferuje. Jak mówiłem dla tej aplikacji overkill, ale to jest projekt do nauczenia się m.in. tego zagadnienia, stąd tak kombinuję.
Baaardzo liczę na podpowiedź od jakiejś doświadczonej osoby w tym temacie.
