Author Archives: Jakub Skoczeń

Routing w ASP.NET MVC

Routing jest to pewnego rodzaju wzór adresu URL, który mapowany jest do odpowiedniej akcji kontrolera lub po prostu do pliku który ma zostać zwrócony. Konfiguracja routingu znajduje się w klasie RouteConfig (w folderze App_Start), w statycznej metodzie RegisterRoutes. Metoda ta wywoływana jest w metodzie Aplication_Start() w klasie MvcApplication z pliku Global.asax.cs. Domyślnie w nowo stworzonym projekcie ASP.NET MVC klasa RouteConfig wygląda tak:

  public class RouteConfig
    {
        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

            routes.MapRoute(
                name: "Default",
                url: "{controller}/{action}/{id}",
                defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
            );
        }
    }

public class RouteConfig

{

public static void RegisterRoutes(RouteCollection routes)

{

routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

routes.MapRoute(

name: "Default",

url: "{controller}/{action}/{id}",

defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }

);

}

W ciele metody RegisterRoutes widzimy wywołanie metody IngoreRoute. Dzięki temu do listy ignorowanych ścieżek zostanie dodana ścieżka wskazująca na jakikolwiek zasób z rozszerzeniem .xsd. Metoda MapRoute, definiuje nam regułę routingu. Należy pamiętać o kolejności definiowanych zasad routingu, ponieważ działa tutaj reguła pierwszego dopasowania, pierwsza pasująca reguła zostanie użyta.
W ASP.NET MVC 5 dodatkowo wprowadzone zostały atrybuty routingu. W celu uruchomienia routingu na podstawie atrybutów należy dodać wywołanie Metody MapMvcAttribytesRoutes w metodzie RegisterRoutes:

routes.MapMvcAttributeRoutes();

1	routes.MapMvcAttributeRoutes();

Atrybuty routingu pozwalają na dekorowanie akcji atrybutem Route z określeniem zasady routingu:

     [Route("{Events}")]
        public ActionResult Index()
        {
            var events = _eventRepository.GetEvents();
            return View(events);
        }

        [Route("{Events}/{id}")]
        // GET: Events/Details/5
        public ActionResult Details(string id)
        {
            if (id == null)
            {
                return new HttpStatusCodeResult(HttpStatusCode.BadRequest);
            }
            Event @event = _eventRepository.GetEventById(id);
            if (@event == null)
            {
                return HttpNotFound();
            }
            return View(@event);
        }

[Route("{Events}")]

public ActionResult Index()

{

var events = _eventRepository.GetEvents();

return View(events);

}

[Route("{Events}/{id}")]

// GET: Events/Details/5

public ActionResult Details(string id)

{

if (id == null)

{

return new HttpStatusCodeResult(HttpStatusCode.BadRequest);

}

Event @event = _eventRepository.GetEventById(id);

if (@event == null)

{

return HttpNotFound();

}

return View(@event);

}

Dodatkowo atrybuty mogą zawierać ograniczenia, np. :

[Route("{Events}/{id:X}")]

1	[Route("{Events}/{id:X}")]

Gdzie X jest ograniczeniem: datetime, decimal, double, float, guid, int, length(n), long, max(n), maxlength(n), min(n), minlength(n), range(n,m), regex(someRegExp).

Pisząc o routingu, należy także wspomnieć o możliwości definiowania obszarów. Kiedy chcemy użyć w naszej aplikacji kilku kontrolerów o takiej samej nazwie (np. jeden do panelu admina, a drugi dla pozostałych użytkowników), przydatne mogą się okazać obszary – RouteArea. Definiując obszar, wyeliminujemy problem wyboru odpowiedniego kontrolera.

[RouteArea("Area1")]
public class EventsController : Controller
{

...

}

[RouteArea("Area1")]

public class EventsController : Controller

{

...

}

Wtedy link do akcji kontrolera z uwzględnieniem obszaru prezentuje się następująco:

Url.Action("Index", "Events", new { Area = "Area1" })

1	Url.Action("Index", "Events", new { Area = "Area1" })

Kontroler i filtry akcji

spa-filters W poprzednim wpisie przyjrzeliśmy się kontrolerom oraz ich akcjom, natomiast teraz rzucimy okiem na filtry, czyli atrybuty, które można zastosować zarówno dla każdej z akcji jak i dla całego kontrolera. Atrybuty definiują nam sposób wykonania określonych akcji. W ASP.NET MVC mamy do dyspozycji kilka typów filtrów akcji:

Filtry autoryzacji – są wywoływane na samym początku, przed pozostałymi filtrami i akcją.
Decydują o możliwości wykonania metody po wcześniejszej autentykacji lub walidacji właściwości danego żądania. Implementują interfejs IAutorizationFilter zawierający metodę OnAuthorization.
Filtry akcji – zapewniają wykonanie dodatkowych operacji, zarówno przed jak i po wykonaniu akcji. Implementują interfejs IActionFilter, który zawiera dwie metody: OnActionExecuting i OnActionExecuted. Pierwsza z nich wykonuje się przed daną akcją, natomiast druga wykonuje się po zakończeniu akcji.
Filtry rezultatu – opakowują wywołanie obiektu typu ActionResult. Implementują interfejs IResultFilter, który zawiera dwie metody podobnie jak interfejs dla filtrów akcji. Jedna z nich to OnResultExecuting i wykonuje się przed zwróceniem rezultatu, a druga to OnResultExecuted i wykonuje się po zwróceniu rezultatu.
Filtry wyjątków – wykonują się gdy nastąpi nieobsłużony wyjątek gdzieś w akcji. Implementują interfejs IExceptionFilter zawierający metodę OnException.

Teraz zobaczmy jak można z tych filtrów skorzystać. Użyjemy najpierw filtra autoryzacji. Chcemy wykonać akcję tylko w momencie gdy użytkownik będzie zautoryzowany. W tym celu dekorujemy naszą metodę atrybutem [Authorize] i to wszystko.

[Authorize]
public ActionResult Delete(string id)
{
  …
}

[Authorize]

public ActionResult Delete(string id)

{

…

}

Kolejnym zaimplementowanym filtrem, którego możemy użyć jest [HandleError], który określa sposób łapania wyjątków.

[HandleError]
public ActionResult Delete(string id)
{
  …
}

[HandleError]

public ActionResult Delete(string id)

{

…

}

W przypadku gdy zechcemy wymusić korzystanie z połączenia po HTTPS wystarczy użyć atrybutu [RequireHttps]

[RequireHttps]
public ActionResult Delete(string id)
{
  …
}

[RequireHttps]

public ActionResult Delete(string id)

{

…

}

Kolejny ważniejszy atrybut to [ValidateAntiForgeryToken], o nim była mowa w jednym z poprzednich postów o CSRF. Za jego pomocą sprawdzane są klucze (ten wygenerowany w formularzu z kluczem przesłanym w żądaniu).

[HttpPost]
[Authorize]
[ValidateAntiForgeryToken]
public ActionResult Edit(Event @event)
{
if (ModelState.IsValid)
{
  …
}
return View(@event);
}

[HttpPost]

[Authorize]

[ValidateAntiForgeryToken]

public ActionResult Edit(Event @event)

{

if (ModelState.IsValid)

{

…

}

return View(@event);

}

Nic nie stoi na przeszkodzie, aby dodawać kilka filtrów do jednej akcji. Możemy również tworzyć własne filtry, implementując odpowiednie interfejsy.
Wspomniałem na początku, że filtry można zastosować nie tylko do konkretnych metod kontrolera, ale też do całej klasy. Można to zrobić np. w ten sposób:

[Authorize]
public class EventsController : Controller
{
…

[Authorize]

public class EventsController : Controller

{

…

Dzięki temu, każda akcja wymaga autoryzacji do wykonania, bez konieczności powielania atrybutu dla każdej akcji.

Oprócz wyżej wymienionych, mamy do dyspozycji jeszcze kilka innych ciekawych atrybutów takich jak:

ValidateInput – walidacja danych wejściowych
HttpGet – obsługa żądania GET, nie trzeba dodawać tego atrybutu, ponieważ domyślnie metoda obsługuje żądania GET
HttpPost – obsługa żądania POST
OutputCache – powoduje cachowanie metody, możliwe jest określenie czasu przechowywania w cachu

Kontroler i Akcje

W tym wpisie przyjrzymy się kontrolerom w aplikacji ASP.NET MVC oraz akcjom, które mogą one zawierać. Kontrolery są odpowiedzialne za odpowiadanie na żądania użytkownika. Każde żądanie kierowane z przeglądarki jest obsługiwane przez określony kontroler. Przykładowo użytkownik klika przycisk odpowiadający za dodanie nowego wydarzenia, natomiast kontroler (EventsController) w odpowiedzi wyświetla odpowiedni widok. Akcja, która się w tym przypadku wykona jest zawarta w metodzie Create typu GET.

// GET: Events/Create
[Authorize]
public ActionResult Create()
{
ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");
ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");
return View();
}

// GET: Events/Create

[Authorize]

public ActionResult Create()

{

ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");

ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");

return View();

}

Zgodnie z dobrymi praktykami należy pamiętać, że w kontrolerze nie powinno być zawartej logiki biznesowej, ani logiki odpowiedzialnej za dostęp do danych. No dobrze, ale jak to się dzieje że akcje są wykonywane przez odpowiednie metody kontrolera? Za to odpowiedzialny jest routing. Przykładowo wywołujemy URL: http://localhost/Events/Create i w tym przypadku zostanie wywołana metoda Create() z klasy EventsController. Akcje kontrolera muszą być metodami publicznymi. Także każda metoda publiczna w kontrolerze staje się wystawioną na zewnątrz akcją. Każda akcja zwraca typ ActionResult. W przypadku powyższej metody Create zwracany jest typ ViewResult. Wystarczy zwrócić wynik metody View(), a zwrócony zostanie widok o nazwie Create znajdujący się w katalogu Events (czyli o takiej samej nazwie jak kontroler). Identyczny efekt osiągniemy gdy wywołamy metodę View(„Create”), wtedy jawnie wskazujemy nazwę widoku. Poza typem ViewResult w ASP.NET MVC jest dostępnych jeszcze kilka innych typów. Lista wszystkich typów prezentuje się następująco:

ViewResult – zwraca widok
PartialViewResult – zwraca widok częściowy
EmptyResult – zwraca null
RedirectResult – przekierowuje do innej akcji za pomocą adresu URL
RedirectToRouteResult – przekierowuje do innej akcji bez odwiedzania adresu URL
JsonResult – zwraca dane w postaci JSON
JavaScriptResult – zwraca kod w postaci JavaScript
ContentResult – zwraca wartość tekstową
FileContentResult – reprezentuje plik do pobrania, jako tablicę bitów
FilePathResult – zwraca ścieżkę do pliku
FileStreamResult – reprezentuje plik do pobrania, jako strumień danych

Każdy z typów dziedziczy z klasy bazowej ActionResult. Poniżej znajdują się przykładowe implementacje akcji:

        public ActionResult Partial()
        {
            var events = _eventRepository.GetEvents();
            return PartialView("Index", events);
        }

        public ActionResult EmptyResult()
        {
            return new EmptyResult();
        }

        public ActionResult RedirectResult()
        {
            var locations = _locationRepository.GetLocations();
            return RedirectToAction("Index", locations);
        }

        public ActionResult RedirectToRouteResult()
        {
            return RedirectToRoute("Index", "Home");
        }

        public ActionResult JsonResult()
        {
            return Json(new { Id = 2016, Name="BreakingChanges" });
        }

        public ActionResult JavaScriptResult()
        {
            return JavaScript("alert('Hello World')");
        }

        public ActionResult ContentResult()
        {
            return Content("TestContent");
        }

        public ActionResult FileContentResult()
        {
            string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "files", "virus.exe");
            return File(System.IO.File.ReadAllBytes(path), "application/x-msdownload");
        }

        public ActionResult FilePathResult()
        {
            string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "files", "virus.exe");
            return File(path, "application/x-msdownload", "virus.exe");
        }

        public ActionResult FileStreamResult()
        {
            string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "files", "virus.exe");
            return File(System.IO.File.OpenRead(path), "application/x-msdownload");
        }

public ActionResult Partial()

{

var events = _eventRepository.GetEvents();

return PartialView("Index", events);

}

public ActionResult EmptyResult()

{

return new EmptyResult();

}

public ActionResult RedirectResult()

{

var locations = _locationRepository.GetLocations();

return RedirectToAction("Index", locations);

}

public ActionResult RedirectToRouteResult()

{

return RedirectToRoute("Index", "Home");

}

public ActionResult JsonResult()

{

return Json(new { Id = 2016, Name="BreakingChanges" });

}

public ActionResult JavaScriptResult()

{

return JavaScript("alert('Hello World')");

}

public ActionResult ContentResult()

{

return Content("TestContent");

}

public ActionResult FileContentResult()

{

string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "files", "virus.exe");

return File(System.IO.File.ReadAllBytes(path), "application/x-msdownload");

}

public ActionResult FilePathResult()

{

string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "files", "virus.exe");

return File(path, "application/x-msdownload", "virus.exe");

}

public ActionResult FileStreamResult()

{

string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "files", "virus.exe");

return File(System.IO.File.OpenRead(path), "application/x-msdownload");

}

Zabezpieczenie przed atakami CSRF w ASP.NET MVC

CSRF czyli Cross-Site Request Forgery jest to w skrócie zmuszenie przeglądarki ofiary do wykonania nieautoryzowanej akcji (za pomocą żądania HTTP). Ofiarą jest zalogowany do serwisu użytkownik. Celem takiego ataku może być podmiana danych w formularzu lub też wykonanie innej akcji np. stworzenie konta użytkownika z uprawnieniami admina. Wypadałoby się przed tym zabezpieczyć tworząc aplikacje webową. Na szczęście mechanizm zabezpieczeń otrzymujemy w ASP.NET MVC out of the box 🙂
Pokażmy to na przykładzie. Mamy kontroler eventów, który zawiera metody Edit – Get i Post.

        // GET: Events/Edit/5
        [Authorize]
        public ActionResult Edit(string id)
        {
            if (id == null)
            {
                return new HttpStatusCodeResult(HttpStatusCode.BadRequest);
            }
            Event @event = _eventRepository.GetEventById(id);
            if (@event == null)
            {
                return HttpNotFound();
            }
            ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");
            ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");
            return View(@event);
        }

        // POST: Events/Edit/5
        [HttpPost]
        [Authorize]
        public ActionResult Edit(Event @event)
        {
            if (ModelState.IsValid)
            {
                try
                {
                    _eventRepository.Update(@event);
                    _eventRepository.SaveChanges();
                }
                catch (Exception ex)
                {
                    ViewBag.Error = true;
                    return View(@event);
                }
            }
            ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");
            ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");
            ViewBag.Error = false;
            return View(@event);
        }

// GET: Events/Edit/5

[Authorize]

public ActionResult Edit(string id)

{

if (id == null)

{

return new HttpStatusCodeResult(HttpStatusCode.BadRequest);

}

Event @event = _eventRepository.GetEventById(id);

if (@event == null)

{

return HttpNotFound();

}

ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");

ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");

return View(@event);

}

// POST: Events/Edit/5

[HttpPost]

[Authorize]

public ActionResult Edit(Event @event)

{

if (ModelState.IsValid)

{

try

{

_eventRepository.Update(@event);

_eventRepository.SaveChanges();

}

catch (Exception ex)

{

ViewBag.Error = true;

return View(@event);

}

ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");

ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");

ViewBag.Error = false;

return View(@event);

}

Teraz wystarczy, że haker skłoni nas do wyświetlenia strony zawierającej formularz z auto submitem, przez niego spreparowany z wpisanymi wartościami, np. strona HTML może zawierać taki kawałek kodu:

<form id="eventForm" action="http://localhost:6875/Events/Edit/88611f5e-fb27-479d-8437-e8e1fe8dcd38" method="post">        
        <input id="Id" name="Id" type="hidden" value="88611f5e-fb27-479d-8437-e8e1fe8dcd38">
        <div class="form-group">
            <label class="control-label col-md-2" for="StartDate">Data rozpoczęcia</label>
            <div class="col-md-10">
                <input class="form-control datepicker text-box single-line" data-val="true" id="StartDate" name="StartDate" type="date" value="2022-04-06">
                <span class="field-validation-valid text-danger" data-valmsg-for="StartDate" data-valmsg-replace="true"></span>
            </div>
        </div>     
</form>
<script type="text/javascript">
    document.getElementById('eventForm').submit();
</script>

<label class="control-label col-md-2" for="StartDate">Data rozpoczęcia</label>

</div>

</form>

document.getElementById('eventForm').submit();

</script>

W przykładzie tym została podmieniona data rozpoczęcia eventu. Nie jest to co prawda jakaś bardzo inwazyjna operacja, ale obrazuje działanie CSRF. W przypadku braku zabezpieczeń, data wybranego wydarzenia zostanie zaktualizowana. Z pomocą przychodzi nam atrybut [ValidateAntiForgeryToken], którym możemy udekorować naszą metodę Edit.

        // POST: Events/Edit/5
        [HttpPost]
        [Authorize]
        [ValidateAntiForgeryToken]
        public ActionResult Edit([Bind(Include = "Id,CreationDate,Name,Description,StartDate,StartTime,EndDate,EndTime,LocationId,TypeId,Objective,NumberOfAttendees,UserId")] Event @event)
        {
            if (ModelState.IsValid)
            {
                try
                {
                    _eventRepository.Update(@event);
                    _eventRepository.SaveChanges();
                }
                catch (Exception ex)
                {
                    ViewBag.Error = true;
                    return View(@event);
                }
            }
            ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");
            ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");
            ViewBag.Error = false;
            return View(@event);
        }

// POST: Events/Edit/5

[HttpPost]

[Authorize]

[ValidateAntiForgeryToken]

public ActionResult Edit([Bind(Include = "Id,CreationDate,Name,Description,StartDate,StartTime,EndDate,EndTime,LocationId,TypeId,Objective,NumberOfAttendees,UserId")] Event @event)

{

if (ModelState.IsValid)

{

try

{

_eventRepository.Update(@event);

_eventRepository.SaveChanges();

}

catch (Exception ex)

{

ViewBag.Error = true;

return View(@event);

}

ViewBag.LocationId = new SelectList(_locationRepository.GetLocations().OrderBy(l => l.Name), "Id", "Name");

ViewBag.TypeId = new SelectList(_eventTypeRepository.GetEventTypes().OrderBy(et => et.Name), "Id", "Name");

ViewBag.Error = false;

return View(@event);

}

Ponadto w widoku musi się znaleźć taki fragment kodu:

@using (Html.BeginForm())
{
@Html.AntiForgeryToken()
…
}

@using (Html.BeginForm())

{

@Html.AntiForgeryToken()

…

}

powoduje to wygenerowanie ciasteczka i klucza, który jest ukryty w formie i wygląda tak:

<input name="__RequestVerificationToken" type="hidden" value="p-mEYr9SQrDvvCGU-ness9maQwrd7iN1ei1FUd5ieKQpXjjGNQKMHyTqER9o9GDqOm4o5cqS27JRWwZBE-R2FUitBnnWI83tMTJ3lq4zrzawzDeAPFKx-3Kf3p5eI1ouRUhfsYWElXnPhGM0fRsWkw2">

1	<input name="__RequestVerificationToken" type="hidden" value="p-mEYr9SQrDvvCGU-ness9maQwrd7iN1ei1FUd5ieKQpXjjGNQKMHyTqER9o9GDqOm4o5cqS27JRWwZBE-R2FUitBnnWI83tMTJ3lq4zrzawzDeAPFKx-3Kf3p5eI1ouRUhfsYWElXnPhGM0fRsWkw2">

W żądaniu POST ciasteczko jest przesyłane i za pomocą atrybutu [ValidateAntiForgeryToken] sprawdzana jest zgodność klucza. Gdy klucz nie będzie zgodny, wystąpi błąd. Dodatkowo w metodzie Edit można dodać jeszcze jedno zabezpieczenie, chodzi o binding.

public ActionResult Edit([Bind(Include = "Id,CreationDate,Name,Description,StartDate,StartTime,EndDate,EndTime,LocationId,TypeId,Objective,NumberOfAttendees,UserId")] Event @event)

1	public ActionResult Edit([Bind(Include = "Id,CreationDate,Name,Description,StartDate,StartTime,EndDate,EndTime,LocationId,TypeId,Objective,NumberOfAttendees,UserId")] Event @event)

Dzięki temu określamy jakie dane mogą zostać zapisane, ponadto w żądaniu sprawdzane są typy i wartości. Poprawność danych wskaże nam właściwość ModelState.IsValid.

Podsumowując, nie należy ignorować podatności CSRF i odpowiednio się przed nią zabezpieczyć. Na szczęście ASP.NET MVC robi to za nas 🙂

DateTime w widoku edycji

Dzisiejszy wpis poświęcony będzie typowi DateTime. Wyświetlając widok edycji zdarzenia, natrafiłem na taki oto problem. Pomimo tego, że zdarzenie ma zapisaną datę, co potwierdza metoda Edit typu GET, więc data powinna zostać załadowane do widoku, tak się jednak nie dzieje.

W widoku zamiast daty rozpoczęcia, widzimy dd.mm.rrrr, dodatkowo możemy wybrać jakąś datę z date pickera (działa tylko w Chrome).

Ten sam przykład w przeglądarce Internet Explorer

W IE nie ma date pickera ponieważ IE nie wspiera typu date, ale data wyświetlana jest prawidłowo. No dobrze to przyjrzyjmy się w takim razie naszemu modelowi. Kod właściwości Data rozpoczęcia prezentuje się tak:

[Display(ResourceType = typeof(Resources.Event), Name = "StartDate")]
[Required]
[DataType(DataType.Date)]
[DisplayFormat(DataFormatString = "{0:dd-MM-yyyy}", ApplyFormatInEditMode = true)]
public DateTime StartDate { get; set; }

[Display(ResourceType = typeof(Resources.Event), Name = "StartDate")]

[Required]

[DataType(DataType.Date)]

[DisplayFormat(DataFormatString = "{0:dd-MM-yyyy}", ApplyFormatInEditMode = true)]

public DateTime StartDate { get; set; }

Kluczowym elementem jest tutaj atrybut DisplayFormat. Aby rozwiązać problem wystarczy zmienić format wyświetlanej daty na yyyy-MM-dd, tylko w taki sposób przeglądarka sobie z tym poradzi. Poprawiony kod właściwości Data rozpoczęcia:

[Display(ResourceType = typeof(Resources.Event), Name = "StartDate")]
[Required]
[DataType(DataType.Date)]
[DisplayFormat(DataFormatString = "{0:yyyy-MM-dd}", ApplyFormatInEditMode = true)]
public DateTime StartDate { get; set; }

[Display(ResourceType = typeof(Resources.Event), Name = "StartDate")]

[Required]

[DataType(DataType.Date)]

[DisplayFormat(DataFormatString = "{0:yyyy-MM-dd}", ApplyFormatInEditMode = true)]

public DateTime StartDate { get; set; }

Taka sama sytuacja ma miejsce w przypadku time pickerów.

Kod w modelu dla właściwości Czas zakończenia wygląda następująco.

[Display(ResourceType = typeof(Resources.Event), Name = "EndTime")]
[Required]
[DataType(DataType.Time)]
[DisplayFormat(DataFormatString = "{0:hh-mm}}", ApplyFormatInEditMode = true)]
public DateTime EndTime { get; set; }

[Display(ResourceType = typeof(Resources.Event), Name = "EndTime")]

[Required]

[DataType(DataType.Time)]

[DisplayFormat(DataFormatString = "{0:hh-mm}}", ApplyFormatInEditMode = true)]

public DateTime EndTime { get; set; }

Po zmianie formatu na hh:mm:ss, problem zostaje rozwiązany. Poniżej kod po poprawkach.

[Display(ResourceType = typeof(Resources.Event), Name = "EndTime")]
[Required]
[DataType(DataType.Time)]
[DisplayFormat(DataFormatString = "{0:hh:mm:ss}", ApplyFormatInEditMode = true)]
public DateTime EndTime { get; set; }

[Display(ResourceType = typeof(Resources.Event), Name = "EndTime")]

[Required]

[DataType(DataType.Time)]

[DisplayFormat(DataFormatString = "{0:hh:mm:ss}", ApplyFormatInEditMode = true)]

public DateTime EndTime { get; set; }

Jak widać format ma znaczenie 😉

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ę 😉

global Plik 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:

public class MvcApplication : System.Web.HttpApplication
    {
        protected void Application_Start()

        {
            AreaRegistration.RegisterAllAreas();
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            BundleConfig.RegisterBundles(BundleTable.Bundles);
        }
    }

public class MvcApplication : System.Web.HttpApplication

{

protected void Application_Start()

{

AreaRegistration.RegisterAllAreas();

FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);

RouteConfig.RegisterRoutes(RouteTable.Routes);

BundleConfig.RegisterBundles(BundleTable.Bundles);

}

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.

        protected void Application_End()
        {
            //...
        }

        protected void Session_Start()
        {
            //...
        }

        protected void Session_End()
        {
            //...
        }

        protected void Application_BeginRequest()
        {
            //...
        }

protected void Application_End()

{

//...

}

protected void Session_Start()

{

//...

}

protected void Session_End()

{

//...

}

protected void Application_BeginRequest()

{

//...

}

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ń.

Dlaczego nie zwracać typu IQueryable w repo?

clip_image001 W ostatnim wpisie poruszyłem tematykę IoC i w przykładowym kawałku kodu dla LocationRepo znajduje się metoda GetLocations zwracająca typ IQueryable. Zwróciła na to uwagę pewna osoba odwiedzająca bloga i słusznie. Stwierdziłem więc, że lepiej będzie rozpisać się krótko na ten temat niż edytować poprzedni wpis. No więc dlaczego zwracanie typu IQueryable<T> jest złe? Można by powiedzieć, że zwracanie ogólnie jest złe i czasem się zdarza 😉 ale do rzeczy.

Implementując repozytorium powinniśmy tworzyć nową metodę dla każdego zapytania, np. GetLocationsByName, GetLocationsBySth, itd. Nie jest dobrą praktyką utworzenie jednej metody albo właściwości zwracającej całą kolekcję typu IQueryable<T>, po to by następnie filtrować elementy przy pomocy LINQ już poza repozytorium. Zapytania LINQ stosowane dla kolekcji IQueryable<T> są tłumaczone na drzewa wyrażeń, które następnie tłumaczone są na język określonego źródła danych, np. SQL. Zwracając z repozytorium taki typ, odpowiedzialność za tworzenie zapytań do źródła danych przechodzi na dewelopera implementującego kod w warstwie wyższej, warstwie domeny. W konsekwencji kod taki nie jest testowalny w 100%. Nie znamy wszystkich możliwych kombinacji zapytań, które mogą występować.
Kolejnym argumentem, który przemawia za niestosowaniem typu IQueryable w repozytoriach, jest to że uzależniamy nasze repozytorium od konieczności używania Entity Frameworka albo LINQ to SQL, ponieważ w przypadku innych źródeł danych musiałby być zaimplementowany mechanizm zwracania IQueryable. Chcemy aby nasz kod był uniwersalny i nie chcemy utrudniać sobie życia implementując dla każdego nowego źródła danych IQueryable, więc jedynym wyjściem jest unikanie tego typu. Oczywiście czasami może się on przydać, jednak musimy mieć to wszystko na uwadze 😉
Poniżej przykład metod zawartych w repozytorium.
Tak nie robimy

      public IQueryable<Location> GetLocations()
        {
            return _ctx.Locations.AsNoTracking();
        }

public IQueryable<Location> GetLocations()

{

return _ctx.Locations.AsNoTracking();

}

lepiej zróbmy to tak

public IEnumerable<Location> GetLocations(int page, int itemsPerPage)
        {
            return
                _ctx.Locations.AsNoTracking()
                    .OrderBy(l => l.Name)
                    .Skip(itemsPerPage*(page - 1))
                    .Take(itemsPerPage)
                    .ToList();
        }

        public Location GetLocationByName(string name)
        {
            return _ctx.Locations.SingleOrDefault(l => l.Name == name);
        }

public IEnumerable<Location> GetLocations(int page, int itemsPerPage)

{

return

_ctx.Locations.AsNoTracking()

.OrderBy(l => l.Name)

.Skip(itemsPerPage*(page - 1))

.Take(itemsPerPage)

.ToList();

}

public Location GetLocationByName(string name)

{

return _ctx.Locations.SingleOrDefault(l => l.Name == name);

}

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.

  public interface ILocationRepo
    {
        IEnumerable<Location> GetLocations();
    }

public interface ILocationRepo

{

IEnumerable<Location> GetLocations();

}

Implementujemy ten interfejs w klasie LocationRepo.

 public class LocationRepo : ILocationRepo
    {
        private readonly ITimePlannerContext _ctx;

        public LocationRepo(ITimePlannerContext ctx)
        {
            _ctx = ctx;
        }

          public IEnumerable<Location> GetLocations()
        {
            return _ctx.Locations.AsNoTracking().ToList();
        }
    }

public class LocationRepo : ILocationRepo

{

private readonly ITimePlannerContext _ctx;

public LocationRepo(ITimePlannerContext ctx)

{

_ctx = ctx;

}

public IEnumerable<Location> GetLocations()

{

return _ctx.Locations.AsNoTracking().ToList();

}

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.

 public class LocationsController : Controller
    {
        private readonly ILocationRepo _repository;

        public LocationsController(ILocationRepo repository)
        {
            _repository = repository;
        }

        // GET: Locations
        public ActionResult Index()
        {
            var locations = _repository.GetLocations();
            return View(locations);
        }
}

public class LocationsController : Controller

{

private readonly ILocationRepo _repository;

public LocationsController(ILocationRepo repository)

{

_repository = repository;

}

// GET: Locations

public ActionResult Index()

{

var locations = _repository.GetLocations();

return View(locations);

}

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.

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.

	   public class UnityConfig
	    {
	        #region Unity Container
	        private static Lazy<IUnityContainer> container = new Lazy<IUnityContainer>(() =>
	        {
	            var container = new UnityContainer();
	            RegisterTypes(container);
	            return container;
	        });
	
	        /// <summary>
	        /// Gets the configured Unity container.
	        /// </summary>
	        public static IUnityContainer GetConfiguredContainer()
	        {
	            return container.Value;
	        }
	        #endregion
	
	        /// <summary>Registers the type mappings with the Unity container.</summary>
	        /// <param name="container">The unity container to configure.</param>
	        /// <remarks>There is no need to register concrete types such as controllers or API controllers (unless you want to 
	        /// change the defaults), as Unity allows resolving a concrete type even if it was not previously registered.</remarks>
	        public static void RegisterTypes(IUnityContainer container)
	        {
	            // NOTE: To load from web.config uncomment the line below. Make sure to add a Microsoft.Practices.Unity.Configuration to the using statements.
	            // container.LoadConfiguration();
	
	            // TODO: Register your types here
	            // container.RegisterType<IProductRepository, ProductRepository>();
	
	            container.RegisterType<AccountController>(new InjectionConstructor());
	            container.RegisterType<ManageController>(new InjectionConstructor());
	            container.RegisterType<ITimePlannerContext, TimePlannerContext>(new PerRequestLifetimeManager());
	            container.RegisterType<ILocationRepo, LocationRepo>(new PerRequestLifetimeManager());
	            container.RegisterType<IEventRepo, EventRepo>(new PerRequestLifetimeManager());
	        }
    }

public class UnityConfig

{

#region Unity Container

private static Lazy<IUnityContainer> container = new Lazy<IUnityContainer>(() =>

{

var container = new UnityContainer();

RegisterTypes(container);

return container;

});

/// <summary>

/// Gets the configured Unity container.

/// </summary>

public static IUnityContainer GetConfiguredContainer()

{

return container.Value;

}

#endregion

/// <summary>Registers the type mappings with the Unity container.</summary>

/// <param name="container">The unity container to configure.</param>

/// <remarks>There is no need to register concrete types such as controllers or API controllers (unless you want to

/// change the defaults), as Unity allows resolving a concrete type even if it was not previously registered.</remarks>

public static void RegisterTypes(IUnityContainer container)

{

// NOTE: To load from web.config uncomment the line below. Make sure to add a Microsoft.Practices.Unity.Configuration to the using statements.

// container.LoadConfiguration();

// TODO: Register your types here

// container.RegisterType<IProductRepository, ProductRepository>();

container.RegisterType<AccountController>(new InjectionConstructor());

container.RegisterType<ManageController>(new InjectionConstructor());

container.RegisterType<ITimePlannerContext, TimePlannerContext>(new PerRequestLifetimeManager());

container.RegisterType<ILocationRepo, LocationRepo>(new PerRequestLifetimeManager());

container.RegisterType<IEventRepo, EventRepo>(new PerRequestLifetimeManager());

}

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.

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:

public ActionResult Index()

{

var locations = _db.Locations.AsNoTracking();

return View(locations.ToList());

}

public ActionResult Index()

{

var locations = _db.Locations.AsNoTracking();

return View(locations.ToList());

}

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

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.

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

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:

<connectionStrings>

<add name="DefaultConnection" connectionString=……

</connectionStrings>

<add name="DefaultConnection" connectionString=……

</connectionStrings>

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

<connectionStrings>

<add name="TimePlannerContext" connectionString=……

</connectionStrings>

<add name="TimePlannerContext" connectionString=……

</connectionStrings>

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

P	W	Ś	C	P	S	N
« Maj
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31