Na chleb – “pep”, a na ASP – “a-ef-e”, czyli raczkowanie w ASP.NET MVC

Mój tort jest już prawie gotowy: spodni biszkopt równomiernie nasiąknął danymi, a środkowa masa osiągnęła spójną konsystencję. Pozostało jeszcze tylko przygotować ostatnią warstwę, dzięki której całość będzie prezentować się iście smakowicie.
Ale dość naśladowania mistrza – przedmiot dzisiejszego wpisu wymaga klarownego języka.

Model – Vidok – Contoler
Struktura MVC polega na podziale pracy aplikacji na trzy segmenty:
– Model – dostarcza informacje o danych, na których program będzie pracować,
– View – odpowiada za formę, czyli to, co widzi użytkownik,
– Controller – realizuje interakcję z użytkownikiem i przepływ danych z Model do View.

Tę właśnie strukturę realizuje Microsoft ASP.NET MVC. Przystępne omówienie tej technologii można znaleźć u źródeł.

Pierwsze kroki
Jak dotąd tworzyłem jedynie programy desktopowe. Aplikacje sieciowe są dla mnie nowością, dlatego skorzystałem z życzliwiości wuja Google i, oprócz informacji teoretycznych, znalazłem sensowanie wyglądający tutorial, z którego postanowiłem skorzystać. Po krótkim przygotowaniu teoretycznym, stworzyłem próbny projekt i wziąłem się za praktykę. Wstępne ujarzmianie kontrolerów i widoków poszło gładko, problem pojawił się natomiast przy próbie wykorzystania projektu InvoiceInvoker jako modelu. Treść problemu była taka: “SQL Server Compact is not intended for ASP.NET development”. Moja reakcja: taka. Nie pozostało nic innego, jak stworzyć nową bazę danych o tych samych tabelach, tym razem używając “normalnej” edycji SQL Server, i ruszyć dalej. Udało mi się oprogramować scenariusze przeglądania, dodawania, edytowania i usuwania produktów (tabela RegisteredProducts bazy danych). Moją euforię zgasił jednak kolejny problem, tym razem niewynikający (mam nadzieję) bezpośrednio z mojego niedopatrzenia: nie potrafię skłonić aplikacji do przeprowadzania walidacji danych wprowadzanych przez użytkownika. Jako że model bazy danych znajduje się w bibliotece zewnętrznej (InvoiceInvoker.Logic.dll), stworzyłem zastępczy model produktu:

using System.ComponentModel;
using System.ComponentModel.DataAnnotations;
using InvoiceInvoker.Logic;

namespace MvcApplication1.Models
{
	public class RegisteredProductModel
	{	
		public int Id { get; set; }
		public int RegisteredSellerId { get; set; }

		[DisplayName("Nazwa")]
		[Required(ErrorMessage="Name required")]
		[StringLength(60, ErrorMessage="Name must be under 60 characters")]
		public string Name { get; set; }

		[DisplayName("PKWiU")]
		[StringLength(20, ErrorMessage = "PKWiU must be under 20 characters")]
		public string Pkwiu { get; set; }

		[DisplayName("Jednostka miary")]
		[Required(ErrorMessage = "Measure unit required")]
		[StringLength(10, ErrorMessage = "Measure unit must be under 10 characters")]
		public string MeasureUnit { get; set; }

		[DisplayName("Cena netto")]
		[Required(ErrorMessage = "Net price required")]
		[Range(0, (double)decimal.MaxValue, ErrorMessage = "Net price must be greater than or equal to 0")]
		public decimal NetPrice { get; set; }

		[DisplayName("Stawka VAT")]
		[Required(ErrorMessage = "Vat rate required")]
		[StringLength(10, ErrorMessage = "Vat rate must be under 10 characters")]
		public string VatRate { get; set; }
	}
}

Według wspomnianego tutorialu, a także tego artykułu, dodanie atrybutów z przestrzeni nazw System.ComponentModel wystarcza do osiągnięcia automatycznej walidacji. Nie u mnie. Właściwość ModelState mojego kontrolera, zachowując pokerową twarz, niezmiennie spełnia warunek: StateModel.IsValid == true.

Próbowałem co najmniej kilku sposobów, jednak w dalszym ciągu nie osiągnąłem tego właściwego, który, jak to bywa w takich przypadkach, zapewne okaże się banalny. Jeśli w końcu znajdę źródło problemu i jego rozwiązanie, poświęcę temu kilka linijek kolejnego wpisu, w którym, mam nadzieję, zaprezentuję również pierwszą uruchamialną wersję programu. Zapraszam!