Przypuszcza się, że mamy N warstw architektury(Przykład: prezentacja, domena, trwałość). Warstwa prezentacji jest aplikacją internetową, ale musimy pamiętać, że moglibyśmy chcieć ponownie wykorzystać domenę i trwałość do innej warstwy prezentacji (takiej jak usługa sieci Web lub aplikacja Windows).
Domena musi implementować całą logikę biznesową z uwzględnieniem uprawnień użytkowników. Teraz moje pytanie brzmi: skąd Domain wie o sesji użytkownika i który użytkownik dzwoni do swoich usług?
Moje interfejsy usługi domenowej (lub umowy) we wszystkich jego metodach będą zawierać parametr wejściowy „UserId” dostarczany przez warstwę prezentacji (domena powinna mieć zaufanie do warstwy prezentacji):
- GetProfileInfo (userId)
- GetUserPendingOrders (userId)
LUB .. Czy sesja użytkownika powinna być komponentem CrossCutting? Jeśli tak, domena będzie wiedziała, który użytkownik dzwoni do jego usługi, więc interfejs będzie:
- GetProfileInfo ()
- GetUserPendingOrders ()
Jak możemy to wdrożyć? Czy istnieje jakiś wzorzec projektowy?
Czy musimy zapisać sesję użytkownika w pamięci? czy jest jakiś inny sposób?
Odpowiedzi:
0 dla odpowiedzi № 1Sesja użytkownika w klasycznym kontekście internetowym jest czymś, o czym wie tylko serwer WWW.
Możesz mieć pojęcie sesji użytkownikatwoją aplikację (jako inny rodzaj obiektu domeny, z własnym repozytorium danych itp.), ale powinieneś być ostrożny, aby nie wiązać / ściśle wiązać tego w jakikolwiek sposób z koncepcją sesji serwera.
To samo dotyczy innych rodzajów aplikacji (WinForm itp.).
Idea UserId nie ma związku z użytkownikiemsesja; na pewno użytkownik może korzystać z systemu (tworząc nową sesję, a być może będziesz w stanie powiązać te dwie rzeczy razem (powyższe przykłady sprawiły, że zastanawiałem się, czy je pomyliłeś).
Czy to problem przekrojowy?
Jeśli ustanowisz sesję użytkownika jako formalny obiekt domeny - odpowiedź brzmi „tak”, ponieważ obiekty domeny (lub reprezentowane przez nich pojęcia) są przekrojowe ale nie w tym samym sensie, co rejestrowanie lub obsługa błędów.
W przeciwnym razie, jeśli sesje użytkownika nie są niczym innym jak (na przykład) sesjami opartymi na serwerze internetowym, wówczas odpowiedź brzmi „nie”, jest to koncepcja specyficzna dla warstwy prezentacji - działająca na serwerze internetowym.
Potem jest trzecia opcja, coś w połowie drogihouse: możesz przekazywać SessionID użytkowników tak, jak przekazujesz inne prymitywne dane - ale tak naprawdę nigdy nie masz obiektu domeny User Session. Musisz tylko być ostrożnym, na przykład jeden rodzaj serwera WWW użyj GUID, inny może użyć int lub ciągu - więc bądź ostrożny.