Global Azure Bootcamp we Wrocławiu!

Witajcie,

zapraszamy na czwarty odcinek codingtv();

Dzisiaj zajmujemy się konfiguracją tabeli routingu w aplikacji ASP.NET MVC. Jak TDD nakazało, najpierw tworzymy testy jednostkowe sprawdzające, czy adresy URL są prawidłowo tłumaczone na klasy i metody kontrolera.

Przy okazji omawiamy integrację Visual Studio z serwerem IIS Express oraz mechanizm szablonów w ReSharperze.

Dzisiejszy odcinek jest podzielony na 3 części (niestety nie udało nam się wyrobić w 30 minut), które tym razem „opakowaliśmy” w playlistę, dzięki czemu poszczególne części powinny się same przełączać.

Zapraszamy do oglądania i czekamy na Wasze komentarze!

Linki do wykorzystywanych pojęć:

22 komentarze

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

  • Klasy RouteHelpers nie ma jeszcze na codeplexie, tak samo z całym projektem od testów, nie zapomnieliście czasem tego uploadnąć ?

  • Kilka spraw:
    1. Rozważaliście użycie VisualHG – bezpośredni dostęp do Mercuriala z VS ?
    2. Warto wykorzystac ignore w mercurialu 🙂
    3. Ctrl+Alt+Space w R# -> dodaje nam automatycznie using statement dla typu, gdy mamy referencje do biblioteki zawierającej ten typ, a Ctrl+Space nie widzi go nadal
    4. W ASP.NET MVC warto wykorzystać bibliotekę MVCContrib, między innymi zawiera helpery do testowania routingu 😉
    5. Raz używacie var, a raz nie. Czy macie jakąś konkretną politykę kiedy używać var a kiedy nie :>
    6. Mercurial & Joel Spolsky -> http://hginit.com/ polecam 😉
    7. Wydaje mi się że warto zostać przy R# 6 EAP. Mam aktualną wersję i nie miałem podobnych problemów, choć miałem inne 😉 W każdym razie późniejsze wsparcie dla Views (Razor) i JavaScript w stosunku do 5.1 nie ocenione 😉
    8. Czy dla NUnit nie rozważaliście użycia semantyki Assert.That do pisania asercji testowych ? Przykład:
    Assert.That(routeData.Route, Is.Not.Null, „No route was matched.”);
    Assert.That(expectedValue.Value.ToString(), Is.EqualTo(routeData.Values[expectedValue.Key].ToString()));

    Ogólnie good job, cały czas odcinki zyskują na wartości 🙂

    • Dzięki Jacku za aktywny udział w naszym projekcie – bardzo nam to pomaga 🙂

      Odnośnie Twojego komentarza:
      – VisualHG wprowadzimy – z Mercuriala nie korzystamy na co dzień (rządzą Vault i SVN) więc dopiero poszukujemy/poznajemy różne narzędzia – wszelkie propozycje mile widziane 🙂
      http://hginit.com – bardzo przydatne!
      – MVCContrib – będzie
      – R#6 – korzystam od pierwszego Nightly Builda i działa na tyle stabilnie, że postanowiliśmy go wykorzystać w nagraniach (tak jak napisałeś wsparcie dla js już jest rewelacyjne i nie wiem jak wcześniej bez niego mogłem programować 🙂 ) ale po włączeniu nagrywania coś się psuje :(. Teoretycznie Camtasia Studio nic nie ma do VS+R# ale coś jest nie tak. Szukamy i postaramy się problemowi zaradzić.

    • Jeszcze odnośnie kwestii poruszonych przez Jacka:

      3. To samo co Ctrl+Alt+Space w R# powinien załatwić nieśmiertelny Alt+Enter (fakt, że trzeba jeszcze raz nacisnąć Enter aby dodać using). Czasem jednak na Alt+Enter nasza wersja R# nie reaguje :/

      5. var: ja osobiście nie mam nic przeciwko var i używam go bardzo często. Dzięki niemu dobrze widać zmienne lokalne, redukuje się „code noise” i zachęca w pewnym stopniu do dobrego nazewnictwa zmiennych. Jest nieocenione przy używaniu karkołomnych konstrukcji LINQ, gdzie ciężko na pierwszy rzut oka stwierdzić co zwróci nam query. Z drugiej strony użycie var absolutnie nie zwalnia z obowiązku bycia świadomym typu zadeklarowanej zmiennej. Ode mnie var dostaje duże TAK.

      8. Semantyka asercji – to również kwestia przyzwyczajeń i osobistych preferencji. Wg mnie zarówno That jak i IsTrue czy Equals są podobnie wygodne.

  • Cześć.

    Właście skończyłem seans z 4 odcinków pod rząd. Co raz ciekawsze, ale tym, co skłoniło mnie do napisania tego komentarza to pytanie (tudzież uwaga) odnośnie architektury.

    Zakładając, że fizyczny podział na 2 projekty to logiczny podział na 3 warstwy – ok. Natomiast tym, co wyróżnia podział warstwowy to elastyczność. Według mnie tego tu zabrakło, poprzez zbyt silne zależność i tak:

    Warstwa dostępu do danych – według mnie – powinna w 100% ukryć sposób przechowywania danych. To znaczy warstwy wyższe nie powinny wiedzieć, czy chodzi o bazę danych, plik XML etc. Dodanie referencji do EntityFramework w projekcie UI spowodowało silne i mało elastyczne zależności. Spowodowało to, że ewentualne tworzenie struktury warstwy DAO na wzorcu repozytorium przestaje mieć sens. UI nie powinno wiedzieć, że do dostępu do danych wykorzystywany jest EF i DbContext.

    Czy nie uważacie (pytam także pozostałych widzów), że bardziej elastyczne podejście to wydzielenie obiektów domenowych (User, Blog, Post) do osobnego projektu – do którego mogą referować wszystkie warstwy. A także udostępnianie przez warstwę dostępu do danych uniwersalnych interfejsów do operacji CRUD i wszystkich innych na danych. Implementacja tych interfejsów to już wrappery na konkretne technologie EF, ADO, XML etc /na przykład realizowane w formie wtyczek/. No rozpędziłem się, bo mam na uwadze rozmiar tworzonego projektu.

    Podejście oczywiście powoduje zwiększony nakład kodu (ale nie jego redundancję) ale zapewnia maksimum elastyczności. I brak potrzeby jakiegokolwiek refaktoru w warstwach BL i UI przy zmianie technologii przechowywania danych. W zasadzie wystarczy tylko napisać podmienić wtedy DLL’kę DAO.

    • Witamy nowego widza 🙂

      Odnośnie Twoich uwag – w pełni się z nimi zgadzamy i docelowo tak będzie wyglądała architektura CodingBlog (no może poza tworzeniem osobnego projektu na obiekty domenowe). Referencja do EF w projekcie UI została dodana tylko po to aby wygenerowała się baza (w następnym odcinku zostanie usunięta). Tak jak mówiliśmy docelowo context EF będzie internal więc nie będzie możliwości korzystania z niego z UI. Był to odcinek o wykorzystaniu CodeFirst oraz generowaniu bazy i chyba faktycznie zabrakło paru słów wytłumaczenia dlaczego tak zrobiliśmy. Oczywiście repozytorium jak i logika biznesowa będą wydzielone poprzez interfejsy. Omówimy to w odcinku 5. W przyszłości chcemy pokazać jak się korzysta z nHibernate, dlatego będziemy się starali zaprojektować repozytorium bardzo elastycznie. Docelowo repozytorium będzie wstrzykiwane poprzez DI.

      Mamy nadzieję, że kolejny odcinek wszystko wyjaśni 🙂

    • codingtv(); będzie istniał tak długo jak długo znajdą się chętni do jego oglądania 🙂

      Nie ograniczamy się w ilości nagranych odcinków. Ciężko jest nam też zaplanować cały projekt, ponieważ chcemy, aby Wasze komentarze miały wpływ na naszą pracę.

      A jak już kiedyś skończymy CodingBlog to na pewno znajdziemy wiele innych tematów, które będziemy mogli tutaj zaprezentować. Zresztą wierzymy, że Wy nam w tym w razie potrzeby pomożecie 🙂

  • Drobna pomyłka językowa :
    TDD = metodyka nie metodologia
    Metodologia = nauka o metodach badań naukowych, ich skuteczności …

  • Witam
    Jako, że tworzę aplikację w wersji Express, mam pytanie odnośnie testów. W jaki sposób je przeprowadzić bez Resharpera ? (niestety nie da się go zainstalować w wersji Express)

  • Ja natomiast odradzam Visual NUnit. W bardziej skomplikowanych testach wyniki mijały się z prawdą 🙂

  • Cześć,

    Na początek słowa pochwały, bo pięknie prowadzicie ten „program” 😉

    A moje przmyślenia:
    wydaje mi się, że commitowanie pliku .csproj z ustawieniami serwera i portu, na który będzie działać aplikacja, nie jest dobre.

    Proponuję zatem odznaczyć checkbox w ustawieniach projektu Web o nazwie:
    „Apply server settings to all users(store in project file)”
    ^^ Tym oto sposobem, każdy programista będzie mógł sobie sam lokalnie ustawić na jakim serwerze chce pracować(IISExpress, IIS7, inne.), a lokalne ustawienia pozostaną zachowane nawet po update projektu z repozytorium.

    Pozdrawiam.

  • Kilka drobnych sugestii:
    Co do testów, to eleganckie jest podejście AAA.
    Moq wymawia się mokju a nie moku 😛
    Pokażcie choć na chwilę NUnit’a, nie każdy ma R# – zwłaszcza początkujący.

    Keep up the good work!