Global Azure Bootcamp we Wrocławiu!

Witajcie!

po dłuższej przerwie zapraszamy Was na szósty odcinek codingtv();

Dzisiaj staramy się naprawić to, co popsuliśmy w poprzednim odcinku – czyli testy do repozytorium Blog.

Dzisiaj pierwszy raz nagranie publikujemy w całości. Dzięki Waszemu zainteresowaniu youtube zdjął ograniczenie długości publikowanych filmów! 🙂

Zapraszamy do oglądania i czekamy na Wasze komentarze!

15 komentarzy

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

  • No nareszcie! 🙂
    A co do odcinka. Tak właściwie, czy serwis przypadkiem nie robi dokładnie tego samego co repozytorium? Oglądając ten odcinek takie właśnie odniosłem wrażenie.

    • Dokładnie, metoda serwisowa, którą napisaliśmy pozwala na odpytanie repozytorium i zwraca wynik. Wszystkie zapytania do bazy będą przechodzić przez warstwę serwisową, w której docelowo znajdzie się cała logika biznesowa aplikacji.

  • Cześć, fajnie prowadzicie ten blog, bardzo mi się podoba 🙂

    Moje propozycje:
    Nie pasuje mi Namespace
    „CodingBlog.Service.Service”

    Proponuje następujące zmiany:
    w projekcie Service, katalogi tworzyć z nazwą związaną z funkcjo0nalnością danej klasy serwisu, czyli np:
    CodingBlog.Service.Blogs i w nim BlogService.
    Interfejs IBlogService.cs proponuję dodać (obowiązkowo) i powiązać w StructureMap lub innym kontenerze IoC – będzie łatwiej pisać unit testy.
    A interfejsy serwisów dodałbym w głównej gałęzi projektu CodingBlog.Service.

    Wydaje mi się, że dla Repository i modelów EntityFramework powinien być osobny projekt np. CodingBlog.Data

    Pewnie będzie trzeba też mapować modele z projektu Web na modele EntityFramework(i odwrotnie). Do tego proponuję rozwiązanie z AutoMapper, który wiele ułatwia.

    Pozdrawiam i raz jeszcze gratuluje pomysłu 🙂
    Marek

  • Jeżeli nowy odcinek będzie w środę (22 czerwca), to zrobicie mi fajny prezent na początek wakacji.

  • cieszę się, że wróciliście do nadawania. Tym razem jedna uwaga ale za to bardzo ważna. PANOWIE, w testach jednostkowych nie dotykamy bazy. To jest karygodny błąd. Jeżeli wasze testy „jednostkowe” dotykają bazy danych to to są testy integracyjne. Takie wykorzystanie testów jednostkowych pokazuje jedynie brak zrozumienia idei unit testing. Testujemy minimalne porcje kodu. Testy muszą być łatwo przenoszalne ponieważ muszą szybko dawać feedback programiście. Jeśli owy programista ma postawić bazę, skonfigurować connection string, serwer i 100000 innych rzeczy to nie będzie korzystał z dobrodziejstw testów jednostkowych.

    • W pełni się z Tobą zgadzam – omawialiśmy to we wcześniejszym odcinku. Chcemy jednak od razu sprawdzić tworzenie schematu bazy na podstawie naszego modelu. W następnych odcinkach zwrócimy większą uwagę na stosowane nazewnictwo.

      PS> Gratuluję 200-tnego komentarza 🙂

  • aa…… jeżeli omawialiście to okej 🙂 chyba poprzedni odcinek oglądałem tak dawno że już zapomniałem.

    Dziękuję za gratulacje 🙂