Global Azure Bootcamp we Wrocławiu!

Witajcie!

po dłuższej przerwie zapraszamy na dziesiąty odcinek codingtv();

Zgodnie z planem w tym odcinku przygotowujemy serwis do klasy User. Jak zawsze serwis pokrywamy testami oraz przygotowujemy kilka mocków.

Poprzednio wywiązała się ciekawa dyskusja na temat sensu wykorzystania repozytorium jako osobnej warstwy w sytuacji, w której wykorzystujemy ORMa. Zgadzamy się z opinią części z Was, że takie rozwiązanie w naszym przypadku jest łagodnie mówiąc nadmiarowe. Postanowiliśmy jednak jeszcze nie zmieniać naszego podejścia tak, aby później sprawdzić/pokazać, na ile takie podejście nam pomoże/przeszkodzi w dalszej implementacji.

Przypominamy również o naszym konkursie – szczegóły w odcinku 🙂

29 komentarzy

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

  • Super, w końcu jest kolejna część, i jest Konkurs!

    PS. Metoda sprawdzenia user „email is in use” powinna nie brać pod uwagę wielkości liter – IgnoreCase

    (girl-power :))

  • Byłoby fajnie dodać w serwisach sprawdzanie argumentów w metodach serwisu np. dla string czy NULL lub Empty. Ale o wiele bardziej ciekawym rozwiązaniem jest użyć do tego Code Contracts.

  • Odcinek super. Ja bym jeszcze w klasie UserService (itd.) dodał funkcję umożliwiającą stworzenie nowego hasła gdy zapomni się obecne hasło. Ale na to chyba przyjdzie jeszcze czas. Konkurs

  • Super, że dalej chce Wam się nagrywać kolejne odcinki! 🙂 A oto moje kilka uwag:

    1. Var – czy na prawdę warto wszędzie używać tego słowa kluczowego zgodnie z podpowiedziami ReSharpera, czy może lepiej dla polepszenia czytelności kodu używać go by nie powielać nazwy typu w jednej linijce kodu (czyli koło new, ale nie przy zmiennych których wartość uzyskujemy z funkcji)

    2. Moim zdaniem zrobiliście błąd w implementacji funkcji CreateUser, sprawdzając zahaszowane hasło. Funkcja Assert.Equals jako parametr przyjmuje wartość oczekiwaną i tą wartością powinna być stała już gotowa wartość. Nie można wyliczać tej wartości w teście gdyż wtedy to sprawdzenie traci sens. Moim zdaniem powinniście wyliczyć konkretną wartość hasza dla tego konkretnego hasła i to ją porównywać. By gdyby Wasza funkcja haszująca nagle przestała liczyć hash i zaczęła zwracać jawne hasło nikt by się o tym nie dowiedział.

    3. Taka pierdółka, ale czy dla późniejszej wygody stosowania nie lepiej zmienić nazwę i zachowanie funkcji EmailIsInUse na IsEmailFree czy podobną negację obecnego zachowania. Gdyż podejrzewam, że częściej będziecie chcieli się dowiedzieć czy ten adres email jest wolny niż,czy jest w użyciu.

    Konkurs! 🙂

  • Można ustawić ReSharpera, żeby nie proponował zamiany wszystkich typów na var? Trochę irytujące jest komunikowanie błędu dla zmiennych typu int itp (które i tak są krótkie, a ułatwiają czytanie kodu).

    Konkurs

  • No nareszcie 🙂
    Panie Łukaszu polecam wyspać się przed następnym nagraniem. 🙂

    Mam takie prywatne odczucie że troszeczkę za długi jest ten odcinek. tak 45 minut jest ok później człowiek się rozprasza.

    Pozdrawiam.
    Konkurs

  • „.. po odcinku rozruchowym po dłuższej przerwie.” 🙂

    Szkoda, że nie pojawiają się nowe odcinki. Jeszcze są osoby które na to czekają (choćby ja, ale patrząc na statystyki online nie jestem jedynym który to regularnie czyta).

    Uwagi techniczne:
    1. Rozważcie powiększenie rozmiaru youtubowego playera do „rozwiniętego” – IMO pozwoliło by to na czytanie w oknie przeglądarki bez fullscreena których przy kilku otwartych oknach nie jest wygodny. Ale do tego musielibyście zmienić layout.
    2. Dźwięk jest dużo lepszy, ale odrobinie głośniej i ludzie półgłusi (jak np. ja) mogliby słuchać na zwykłych słuchawkach.

    Pytanie do odcinka:
    Kiedy mockujemy funkcje GetUserByEmailAndPassword z UserRepository podajemy w wyrażeniu lambda konkretne wartości email oraz hashedPassword, sprawdziłem dla różnych wartości i zobaczyłem, że nie ma to znaczenia – czy jest możliwość stworzenia mocka który zwraca różne wartości dla różnych wartości email i hashedPassword?

    Pozdrawiam i życzę sobie i Wam kolejnych odcinków,
    Michał

    • Dzięki za posta – to dodatkowo motywuje do działania 😉

      Obiecujemy, że już wkrótce pojawią się nowe odcinki!

      Co do powiększenia playera – coś pomyślimy.

  • Właśnie skończyłem oglądać waszą serię i jest na prawdę fajnie!
    1. W międzyczasie kiedy tworzyliście serwis wyszło MVC4 – myśleliście może nad przesiadką? Bardziej mam na myśli pokazanie jak się to robi niż zrobienie tego w celu osiągnięcia jakiś korzyści przy implementacji (chociaż te także będą).
    2. Fajnie by było jakbyście po każdym odcinku commitowali zmiany na CodePlexie. Najlepiej z nr odcinka w komentarzu (oprócz tego co się zmieniło).
    3. Potwierdzam uwagę Grzegorza. Długość odcinka ok.45 min. jest w sam raz. 1:15 to trochę przydługo.

    Tak samo jak koledzy powyżej nie mogę się doczekać kolejnego odcinka!
    Konkurs!

  • No panowie proszę nie dajcie więcej nam czekać na kolejne odcinki. Dobrze popatrzeć „jak to się robi”. Nie interesuje mnie ASP.net ale za to uczę się właśnie jak to się robi.