Category Archives: ASP.NET MVC

Do czego służy plik Global.asax?

W aplikacji webowej ASP.NET MVC możemy znaleźć plik Global.asax zawierający klasę MvcApplication dziedziczącą po klasie HttpApplication. Postanowiłem poświęcić temu kolejny wpis, ponieważ myślę że warto opisać do czego on służy, tym bardziej że pytanie to może być także zadane na rozmowach o pracę 😉

globalPlik Global.asax jest to opcjonalny plik zawierający kod, który odpowiada za reagowanie na zdarzenia zgłoszone z poziomu aplikacji i poziomu sesji takie jak start aplikacji, zakończenie sesji, itp. Plik ten jest opcjonalny, czyli nie musimy reagować na te zdarzenia, jeżeli nie chcemy.
Domyślnie plik ten zawiera następujący kod:

Jak widać jest tutaj tylko zaimplementowane obsłużenie zdarzenia startu aplikacji, jednak nic nie stoi na przeszkodzie, aby dodać obsługę innych zdarzeń.
W tym celu wystarczy dodać odpowiednio nazwaną metodę/metody np.

To wszystko, nie musimy robić nic więcej (poza implementacją reakcji na zdarzenie). Gdy zdarzenie zostanie zgłoszone, zostanie ono odpowiednio obsłużone.
Lista zdarzeń wraz z krótkim opisem każdego z nich prezentuje się następująco:

Application_Init: pojawia się podczas inicjalizacji aplikacji albo pierwszego wywołania.
Application_Disposed: pojawia się zaraz przed końcem życia aplikacji. Idealne miejsce do zwolnienia używanych zasobów.
Application_Error: pojawia się podczas wystąpienia błędu, który nie został obsłużony w aplikacji.
Application_Start: pojawia się podczas stworzenia pierwszej instancji klasy HttpApplication. Pozwala na stworzenie obiektów dostępnych we wszystkich instancjach HttpApplication.
Application_End: pojawia się, kiedy ostatnia instancja klasy HttpApplication kończy swój cykl życia. Odpalany tylko raz.
Application_BeginRequest: pojawia się podczas odebrania żądania aplikacji. Jest to pierwsze odpalane zdarzenie.
Application_EndRequest: jest to ostatnie zdarzenie, które pojawia się podczas żądania aplikacji.
Application_PreRequestHandlerExecute: pojawia się przed wykonaniem obsługi zdarzenia strony albo web serwisu.
Application_PostRequestHandlerExecute: pojawia się na koniec wykonania obsługi zdarzenia.
Applcation_PreSendRequestHeaders: pojawia się przed wysłaniem nagłówków HTTP do klienta wysyłającego żądanie (przeglądarka).
Application_PreSendRequestContent: pojawia się przed wysłaniem zawartości do klienta wysyłającego żądanie (przeglądarka).
Application_AcquireRequestState: pojawia się podczas pobrania bieżącego stanu (stanu sesji) związanego z bieżącym żądaniem.
Application_ReleaseRequestState: pojawia się podczas zakończenia wykonania obsługi wszystkich zdarzeń.
Application_ResolveRequestCache: pojawia się, kiedy zakończy się autoryzacja, by pozwolić modułom cachującym obsługiwać żądania z cachu obchodząc wykonania obsługi zdarzenia np. strony lub web serwisu.
Application_UpdateRequestCache: pojawia się po zakończeniu wykonania obsługi zdarzenia, by pozwolić modułom cachującym przechowywać odpowiedzi do obsługi kolejnych żądań.
Application_AuthenticateRequest: pojawia się, gdy moduł zabezpieczeń ustali tożsamość bieżącego użytkownika. Od tego momentu poświadczenia użytkownika są zatwierdzone.
Application_AuthorizeRequest: pojawia się, gdy moduł zabezpieczeń zweryfikuje, że użytkownik może uzyskać dostęp do zasobów.
Application_MapRequestHandler: pojawia się, gdy procedura obsługi jest wybrana do odpowiedzi na żądanie.
Application_PostLogRequest: pojawia się podczas zakończenia przetwarzania obsługi wszystkich zdarzeń dla zdarzenia LogRequest
Session_Start: pojawia się, gdy nowy użytkownik odwiedzi stronę aplikacji.
Session_End: pojawia się, gdy sesja użytkownika przekroczy limit czasu, zakończy się albo strona aplikacji zostanie opuszczona.

Warto o tym wiedzieć, bo być może kiedyś przyda nam się obsługa któregoś ze zdarzeń.

Jak dodać kontener IoC?

Doctor with a syringe and patient. Isolated over white

Co to jest kontener IoC? IoC czyli Inversion of Control lub też odwrócenie zależności, brzmi bardzo ogólnie, ale co się pod tym kryje?
Możemy tutaj zaliczyć wzorzec fabryki, service locatora (lub też antywzorzec), czy też dependency injection i na tym ostatnim się skupimy.
Wzorzec ten może zostać zaimplementowany np. poprzez: constructor injection, property injection, jednak najbardziej sensowny jest ten pierwszy sposób.
Polega on na wstrzyknięciu zależności poprzez konstruktor. Kontener IoC ma nam w tym wszystkim pomóc, chodzi o to aby wstrzyknął on za nas jakiś konkretny typ, np. za typ ILocationRepo zostanie wstrzyknięty LocationRepo.

Po co nam to panie? No to zacznijmy od początku…
W przypadku web aplikacji ASP.NET MVC, domyślnie stworzony kontroler zawiera w sobie logikę, jednak dobrą praktyką jest wydzielenie warstwy logiki. W tym celu stworzyłem repozytoria w osobnym projekcie. Jednak aby wykorzystać dane repozytorium w kontrolerze, nie chcemy tworzyć instancji konkretnej klasy, chcemy być bardziej elastyczni i w razie potrzeby wstrzyknąć w to miejsce nową implementacje repozytorium. Do tego celu zastosujemy Dependency Injection i kontener IoC.

Pierwsza rzecz, która pozostaje do zrobienia to implementacja interfejsów dla każdego repozytorium oraz dla kontekstu. Tworzymy przykładowo interfejs dla repozytorium Location. Na razie zawiera on tylko metodę GetLocations(), jednak później będzie on zawierał więcej metod.

Implementujemy ten interfejs w klasie LocationRepo.

Widzimy tutaj także typ ITimePlannerContext – jest to interfejs naszego kontekstu, który także należy stworzyć, aby nie uzależniać się od konkretnego kontekstu w repozytoriach. Następnie możemy już przejść do kontrolera i stworzyć w nim konstruktor, który umożliwi nam constructor injection.

Ok, ale skąd wiadomo jaką implementację wstrzyknąć pod dany interfejs? Do tego posłuży nam kontener IoC.

Jak dodać kontener IoC?
Poniżej przedstawię użycie kontenera Unity, jednak rozpocząłem też zabawę z Autofac i chyba w późniejszym czasie skorzystam z niego, ale o tym może później. Gdyby ktoś był ciekawy jak wypadają inne kontenery w porównaniu, szukając w sieci trafiłem na ciekawy link.
Teraz czas przedstawić jak zastosować Unity. Otwieramy NuGet package managera i wyszukujemy Unity.Mvc, instalujemy w naszej web aplikacji.

clip_image001

clip_image002

Po zainstalowaniu paczki, do folderu App_Start w naszej aplikacji zostaną dodane dwie dodatkowe klasy: UnityConfig i UnityMvcActivator. Przechodzimy do klasy UnityConfig i przystępujemy do implementacji metody RegisterTypes, w której zdefiniujemy które klasy implementują określone interfejsy. Kod całej klasy wygląda następująco.

W metodzie RegisterTypes jak sama nazwa wskazuje, rejestrowane są typy i tak np. za typ ILocationRepo podstawiamy LocationRepo, itd. W przypadku gdy stworzymy nową wersję LocationRepo i będziemy chcieli z niej korzystać, to wystarczy tylko ją tutaj zarejestrować i to wszystko. Oczywiście gdyby ktoś chciał można też wykorzystać w tym miejscu refleksję i wtedy zwolni nas to z obowiązku rejestrowania każdego nowego typu. Teraz możemy uruchomić aplikację i sprawdzić efekt. Bardzo proste prawda? Za to ile korzyści 😉

Do czego służy metoda AsNoTracking()?

Korzystając z Entity Frameworka warto zwracać uwagę na sposób pobierania danych.
W przypadku, gdy nie będziemy ich modyfikować, a chcemy jedynie pobrać dane tylko do odczytu, przydatna okaże się metoda AsNoTracking(). Wywołanie metody skutkuje brakiem śledzenia danych przez kontekst. Dzięki temu nie marnujemy niepotrzebnie zasobów.
Przyjrzyjmy się poniższemu przykładowi, w którym porównamy pobieranie danych z i bez metody AsNoTracking(). Na początek pobieramy dane standardowo. W tym celu modyfikujemy metodę Index() kontrolera LocationsController i debugując przechodzimy za linię kodu odpowiadającą za zwrócenie danych do widoku. W okienku watch podglądamy nasz obiekt kontekstu i widzimy, że 4 lokalizacje zostały do niego zapisane.

clip_image001

Teraz czas na wywołanie metody AsNoTracking() i upewnienie się, że dane nie są zapisywane w kontekście. Tym razem metoda Index() prezentuje się następująco:

Debugujemy, przechodzimy za ostatnią linię kodu w metodzie Index() i podglądamy nasz obiekt kontekstu.

clip_image002

Jak widać lokalizacje nie zostały tym razem zapisane do kontekstu, nie są przez niego śledzone. W tym przypadku oszczędności pamięci są niewielkie, ale wyobraźmy sobie gdybyśmy mieli takich lokalizacji tysiące, spowodowałoby to niepotrzebne straty. Dlatego należy zwrócić szczególną uwagę w takich sytuacjach i stosować AsNoTracking(), tam gdzie tylko jest to możliwe.

Exception has been thrown by the target of an invocation

Dodając kontroler – MVC 5 Controller with views, using Entity Framework. Możemy napotkać pewien problem.

clip_image001

Po kliknięciu Add pojawia się błąd: Exception has been thrown by the target of an invocation.

clip_image002

Googlując możemy znaleźć dosyć dużo osób mających taki sam problem, jednak większość proponowanych rozwiązań nie dawała w moim przypadku rezultatu, np. reinstalacja paczki EntityFramework. Niektórzy proponowali aktualizację Visual Studio, jednak tyczy się to tylko VS2013. Próbowałem nawet użyć VS2013, jednak było to samo. Rozwiązanie okazało się bardzo proste, wystarczyło edytować connection stringa w pliku Web.config. Wcześniej zmieniłem domyślną nazwę klasy kontekstu, ale nie wprowadziłem zmian do Web.configa.
Było:

należało zmienić nazwę na dokładnie taką samą jak klasa kontekstu czyli:

Ta da, działa!
Kontroler został utworzony jak również widoki. Błąd jest banalny, ale może ktoś napotka ten sam problem i dzięki temu wpisowi zaoszczędzi kilka minut Puszczam oczko