Najlepszy pattern dla zwrocenia innych encji dla zalogowanego oraz niezalogowanego uzytkownika.

Czesc, borykam sie z pewnym problemem. Mam juz to zrobione, ale zastanawiam sie czy to dobry sposob, a moze jest lepszy. A mianowicie chodzi o to, ze chcialbym zwracac inne dane dla uzytkownika ktory jest zalogownay, a inne dla ktorego nie jest zalogowany. Rozwiazalem to mniej wiecej tak.

        private IQueryable<SomeAuthorized> UserData(int userId)
        {
            // SELECT FROM BLA BLA WHERE ID = userId select new SomeAuthorized {bla bla}
        }
       private IQueryable<SomeUnauthorized> UserData() 
        {
            // SELECT FROM BLA BLA select new SomeUnauthorized {bla bla}
        }

Teraz zwracamy wyniki, ktore chcemy dla odpowienich typow (SomeAuthorized lub SomeUnauthorized )

        private object UserPresenter(SomeAuthorized  entity)
        {
            return new object {authorized = true, ...};
        }
       private object UserPresenter(SomeUnauthorized entity) 
        {
           return new object {authorized = false, ...};
        }

Jest to spoko podejscie, czy znacie moze lepsze ? licze na pomoc.

Pozdrawiam

Ja nie wiem czy chciałbym zwracać object... Później to musisz pewno jakoś rzutować, sprawdzać czy się udało itp. Zwróć po prostu inny obiekt i sprawdzaj czy jest null-em .

Stworz sobie po prostu interfejs
HandleUser
i posiadaj tam jakies funkcje do oblsugi (np UserData czy UserPresenter)
pozniej dziedzicz tym interfejsem do dwoch klas
RegisteredUser
NotLoggedInUser
w kazdym zaimplementuj te funkcje do obslugi osobno. Pozniej wystarczy zrobic jakis Factory ktore na podstawie jakies zmiennej (ktora determinuje czy jest to zalogowany uzytkownik czy nie) tworzysz odpowiednia klase

kod wtedy bedzie lepszy do testowania i bedziesz mogl mockowac zaleznosc (bo masz interfejs)

@ne0 tak, nie chcialem zwracac typu obiekt, tylko tak prototypowo wpisalem.

@fasadin spoko pomysl, ale mam jeszcze jeden problem, powiedzmy ze presenter w jednym i drugim posiada duzo atrybutow i 3/4 sie pokrywa, to powiedzmy ze duplikujemy kod, przy dwoch grantach jeszcze nie jest tak zle, ale jak dojdzie nowy typ (nwm. np. IsAdmin), to juz mamy 3x prawie taki sam kod do zwracania atrybutow do aplikacji.

Myslalem o tym, aby stworzyc klase np. UserPresenter i w jego konstruktorze np. wywolac to co robi teraz UserPresenter(SomeUnauthorized entity) bo sa to minimalne atrybuty jakie moze posiadac kazdy user. Pozniej byloby mozna dziedziczyc UserPresenter i podmieniac wartosci atrybutow na takie jakie potrzebujemy. Co o tym myslicie ?

ale po co masz duplikowac? Jezeli tak to mozesz zrobic klase ktora zawiera te propertisy i wtedy robisz prosta kompozycje. Properties beda miec wlasna klase z wlasna logika ktora wywolasz raz. Nie powinienes duplikowac kodu ;)

Zawsze mozesz zrobic jakas klase bazowa pomiedzy interfejsem a tymi dwoma klasami, ale nie jest to dobre rozwiazanie bo ciezko sie takie testuje (czesto takie base classy maja zaleznosci ktore ciezko rozwiazac)

Mało kodu pokazałeś i ciężko stwierdzić o co tu w ogóle chodzi. Nie wiadomo o jakiego rodzaju dane chodzi, ani też w jaki sposób sprawdzasz czy użytkownik jest zalogowany.

Okej, mysle ze prawie mam juz stworzony kod, ale mam jeszcze jeden problem. Teraz istnieja dwie klasy RegisteredUserData oraz IsNotLoggedInUserData i w controllerze mam cos takiego:

      private RegisteredUserData RegisteredUserData ;
      private IsNotLoggedInUserData IsNotLoggedInUserData ; 

      public Controller(
            RegisteredUserData RegisteredUserData,
            IsNotLoggedInUserData IsNotLoggedInUserData)
        {
            this.userData = HttpContext.Current.GetUser() != null ? RegisteredUserData: IsNotLoggedInUserData;
        }

Jak moge to zcastowac, tak zeby nie rzuacal bledem ? :/

A jakiego typu jest this.userData?

I czemu zaczynasz nazwy parametrów metod wielką literą, dzięki czemu dodatkowo stają się nieodróżnialne od nazw typów? :|

Zrobilem mniej wiecej cos takiego

 private RegisteredUserData RegisteredUserData ;
     private IUserData UserData;
 
      public Controller(
            RegisteredUserData RegisteredUserData,
            IsNotLoggedInUserData IsNotLoggedInUserData)
        {
            this.UserData = HttpContext.Current.GetUser() != null ? (IUserData)RegisteredUserData: (IUserData)RegisteredUserData;
        }

Obie klasy dziedzicza po interejsie IUserData. Rozwiazanie niby dziala, ale denerwuje mnie to, ze musza miec wspolny interfejs (te 2 klasy), a jesli chcialbym dodac do jednej parametry to juz niestety interfejs sie nie bedzie zgadzal i nie wiem jak to obsluzyc.

Dzialajacy wyglada tak

        public interface IUserData
         {
          IEnumerable<PresenterDto> Some(int userId = nul);
          IEnumerable<PresenterDto> Some2(int userId= null);
        }
       

A chcialem zrobic cos takiego

        public interface IRegisteredUserData
         {
          IEnumerable<PresenterDto> Some(int userId = nul);
          IEnumerable<PresenterDto> Some2(int userId= null);
        }
       

        public interface INotLoggedInUserData
         {
          IEnumerable<PresenterDto> Some();
          IEnumerable<PresenterDto> Some2();
        }
       

Z tym drugim rozwiazaniem nie wiem jak to w kontrollerze obsluzyc, dlatego zrobilem to 1 rozwiazanie.

Hm.. chyba jednak nie dziala, bo wchodzi caly czas do niezalogowanego uzytkownika (klasy) mimo ze prawidlowo dostaje token.

HttpContext.Current.User.Identity.IsAuthenticated zwraca false w konstruktorze. Istnieje moze jakas metoda, w ktorej moglbym to umiescic, tak zeby controller w konstruktorze juz zalapal Identity ?

Mały Lew napisał(a):

Obie klasy dziedzicza po interejsie IUserData. Rozwiazanie niby dziala, ale denerwuje mnie to, ze musza miec wspolny interfejs (te 2 klasy), a jesli chcialbym dodac do jednej parametry to juz niestety interfejs sie nie bedzie zgadzal i nie wiem jak to obsluzyc.

Normalnie - mieć dwie metody, albo tak zaprojektować logikę, żeby metoda otrzymująca obiekt typu interfejs nie musiała znać dokładnego typu klasy.

Mały Lew napisał(a):

HttpContext.Current.User.Identity.IsAuthenticated zwraca false w konstruktorze. Istnieje moze jakas metoda, w ktorej moglbym to umiescic, tak zeby controller w konstruktorze juz zalapal Identity ?

Kontroler w konstruktorze nigdy nie dostanie prawidłowej wartości Identity, bo ona jest uzyskiwana w trakcie interpretowania requestu HTTP.

Mnie tutaj jakby od początku brakuje wyjaśnienia tego, co dokładnie chcesz zrobić, jaki efekt uzyskać.

Normalnie - mieć dwie metody, albo tak zaprojektować logikę, żeby metoda otrzymująca obiekt typu interfejs nie musiała znać dokładnego typu klasy.

Mozesz to jakos pokazac?
Ogolnie juz udalo mi sie wszystko zrobic, mysle ze wyszlo dosyc spoko. Zrobilem to dzieki getterom.

Ja mam wrażenie, że nasza komunikacja przebiega na zupełnie innych poziomach abstrakcji. ;) Tzn. ja mówię, że pod budowę wieżowca musisz mieć 20m fundamentów, a Ty, że udało Ci się wymieszać zaprawę. Bez urazy, ale naukę programowania lepiej zacząć od aplikacji konsolowych, żeby zrozumieć pewne podstawowe koncepcje, a dopiero potem zająć się webem.

@somekind spoko, mam na tyle poziomu, zeby ruszac web, tylko nie znam jeszcze dobrze c# i asp, zeby w tym plywac.
Temat do zamkniecia.