Z życia ASP.NET MVC

Zapewne większość z Was miała do czynienia z aplikacjami pisanymi przy wykorzystaniu ASP.NET MVC. Zapewne pracowaliście nad jakimś projektem, im bliżej końca, tym co raz częściej wkradają się błędy, aplikacja jest na tyle duża, że łatwo wstawić przez przypadek do widoku jakieś duperele, jest mnóstwo resource’ów, które bardzo ciężko ogarnąć, mapowanie view-model to jakiś koszmar.

Brzmi źle? Wcale nie musi tak być. Oto kilka porad (subiektywnych), w jaki sposób możemy uniknąć bałaganu:

1) Razor Generator dla widoków – o tym pisałem już wcześniej – Razor Generator – po pierwsze widoki są kompilowane w trakcie budowania projektu, po drugie – klasa znajdująca się pod spodem widoku jest przegenerowywana przy najdrobniejszej zmianie, więc jest to łatwe do wychwycenia w chwili check-in’u.

2) Twórzcie klasy ViewModel. Nie używajcie klas domenowych w widokach. Do ułatwienia procesu mapowania – AutoMapper

3) Wykorzystujcie wstrzykiwanie zależności (DI). Pomaga to utrzymać porządek w kodzie.  Można bawić się w DI by hand, jednak zdecydowanie polecam Ninject w małych projektach, a Unity w dużych.

4) Stosujcie TDD – Test Driven Development. Łatwiej jest utrzymać porządek oraz mieć pewność, że wszystkie elementy są przetestowane. Bardzo ciekawym i ułatwiającym pracę z testami narzędziem jest nCrunch (NCrunch)

5) Ułatwienie pracy ze środowiskiem – tutaj nie będę oryginalny, zainwestujcie w ReSharper’a

6) Nie umieszczajcie zaawansowanej logiki w akcjach kontrolera, twórzcie dodatkowe klasy odwołujące się do repozytorium oraz klasy wywołujące je – niech kontroler korzysta z najwyższej warstwy, nie korzystając przy tym z klas domenowych.

7) Od wyjścia na świat EF 5, gdy macie wybór pomiędzy nHibernate, a EF – stosujcie EF. W mniejszych projektach Code First, w większych DB First.

8) Od samego początku projektu stosujcie Code Review. Ułatwi to kodzenie w późniejszych fazach.

I to chyba tyle. Może macie jakieś dodatkowe przemyślenia na ten temat, jakieś inne rady?

10 thoughts on “Z życia ASP.NET MVC

  1. Czym wyróżnia się EF na tle nHibernate? Moim zdaniem oba wspomniane narzędzia są godne polecenia. Jedyne co mi przychodzi na myśl to prostota konfiguracji daję EF przewagę nad NH.

    1. Rzeczywiście, prostota konfiguracji jest tutaj jednym z najważniejszych czynników. Integracja z LINQ, user friendly. Kolejna rzecz – po co sięgać po rozwiązania spoza framework’a? Przewaga nHibernate do niedawna polegała na tym, że dostępne były interceptors czy 2nd level cache, czego w EF nie było. Od EF6 na szczęście już się to zmieniło. Koelejna rzecz – automatyczne przegenerowywanie klas domenowych poprzez kliknięcie na zintegrowanym modelu opcji update from database. Oczywiście kolejnym plusem są trzy różne podejścia: code first, model first, database first. Przy ostatniej opcji wygląda to mniej więcej tak: zmieniasz coś w bazie danych, np. dodajesz tabelę. Następnie klikasz na modelu w projekcie update from database i już. Cały kod klas domenowych jest przegenerowany, na modelu pojawiają się relacje itp. Jedynym minusem jest to, że trzeba ręcznie usuwać properties’y z istniejącego modelu.

      Wiadomo, zwolenników nHibernate jest tylu ilu zwolenników Entity Framework, jednak pytanie brzmi: Czy chcę sobie utrudniać życie? 🙂

      1. Niestety w Twojej opinii na temat database first jest bardzo poważna rysa. Senk w tym, że wszelkie zmiany są zapisywany w xml’u, który bardzo ale to bardzo źle się merguje (praca z nim w dużym zespole przy dużym projekcie to wejście do 9 kręgu piekieł :-). Przy dużych projektach polecam podejście Code First, a narzędziem do migracji Fluentmigrator’a.

      2. Powiem tak – do tej pory nie stanowiło to praktycznie żadnego problemu, ponieważ w momencie gdy jedna osoba pracowała z modelem, to robiła check out z lockiem i reszta nie mogła go modyfikować. Nigdy nie było to bolączką, nawet w bardzo dużych projektach. Natomiast rzeczywiście, może w momencie, gdy kilka osób potrzebuje skorzystać w tym samym momencie z bazy i modelu to stanowi problem – nie chcę się na ten temat wypowiadać, ponieważ nigdy w takiej sytuacji nie byłem 🙂 Code First bardzo lubię, natomiast tu pojawia się inna kwestia – czasem trzeba doedukować członków zespołu, żeby nie narobić bałaganu. Wydaje mi się, że na początku DB First jest łatwiejsze i przyjemniejsze.

  2. Tak odnosnie 7 – dlaczego taka kolejnosc a nie odwrotna?
    Co do 6 to lepiej dodac warstwe serwisowa – w wiekszych projektach kontroler nie powinien dotykac repozytorium i obiektow domenowych.
    Dodalbym jeszcze 9 – stosowac klasy generyczne
    10 – spisac ogolne zalozenia odnosnie kodowania – aby 2 roznych developerow nie rozwiazywalo podobnych problemow w rozne sposoby

    1. Co do 6 – masz rację, to był skrót myślowy, dobrze, jeśli mamy jakiś manager, któy odwołuje się bezpośrednio do repozytorium oraz drugą klasę z metodami wywołującymi metody z manager’a, po czym kontroler korzysta właśnie z tej najwyższej warstwy (nie korzystającej bezpośrednio z obiektów domenowych). Co do 7 – chodzi Ci o Code First, a DB First? Miałem okazję pracować z Code First i DB First i wg mnie, wygodniej jest stosować DB First przy większych projektach, łatwiej to wszystko ogarnąć.

  3. ” jednak zdecydowanie polecam Ninject w małych projektach, a Unity w dużych.”

    Czemu uważasz, że Ninject jest gorszy w dużych projektach?

    1. Może inaczej – to zdanie jest dwuznaczne – Unity to ogromna kobyła, której nie polecam do używania w małych projektach. Ninject jest natomiast uniwersalny, z resztą jestem jego fanem. Także Unity tylko i wyłącznie w dużych projektach, a Ninject i w tych i w tych.

      1. OK, teraz rozumiem. Z unity nie korzystałem, a z Ninject pracuję na codzień i jest spoko 🙂

Zostaw komentarz

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj / Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj / Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj / Zmień )

Connecting to %s