ViewData Model
Cóz to za potworek wielu pewnie zapyta. Są to modele(klasy) używane do przekazywania danych z kontrolera do widoku. Dzięki niemu widoki mogą być silnie typowane na konkretny model. Możemy dzięki temu uniknąć używania ViewData i mamy wszystkie dane z widoku ładnie w jednym modelu. Znacznie ułatwia to dostęp do danych. Nie będę tutaj się za bardzo rozpisywał na ten temat ale znacznie rozbudowane wytłumaczenie możecie znaleźć na tym blogu
U mnie struktura ViewDataModel wygląda tak:
BaseViewData - jest to model z Site.Mastera czyli wszystkie dane które potrzebujemy do głównego szablonu. Miedzy innym meta słowa, tytuł, menu etc. Wszystkie inne ViewData Modele dziedziczą po tym. Implementacja:
public class BaseViewData { public string SiteTitle { get; set; } public string PageTitle { get; set; } public string MetaKeywords { get; set; } public string MetaDescription { get; set; } }Następnie jest konkretny ViewDataModel dotyczący kontrolera np. AccountViewData który to w konstruktorze ustawia tytuł strony. Przykladowa implementacja dla kontrolera Account:
public class AccountViewData : BaseViewData { private string _pageTitle = "Account"; public AccountViewData() { PageTitle = _pageTitle; } }A potem już konkretne widoki posiadają Modele które dziedziczą z danego modelu kontrolera np:
public class LogOnViewData : AccountViewData { [Required] [DisplayName("User name")] public string UserName { get; set; } [Required] [DataType(DataType.Password)] [DisplayName("Password")] public string Password { get; set; } [DisplayName("Remember me?")] public bool RememberMe { get; set; } }Generowanie ViewData modeli odbywa się za pomocą fabryki po to aby konkretny kontroler nie musiał wiedzieć on zmiennych z Site.Mastera. Przykładowe utworzenie ViewData modelu dla kontrolera Account widoku logowania
public ActionResult LogOn() { LogOnViewData view = _viewDataFactory.Create<LogOnViewData>(); return View(view); }
Commands
Następny element związany z widokami to commandy. Sa one używane do bindowana danych które przesyła nam formularz do konkretnego kontrolera. Dzięki temu możemy napisać
public ActionResult Register(RegisterCommnad command)zamiast:
public ActionResult Register(FormCollection formitems)i z tego wyciagac pola.
Automapper
Automapper jest to mala biblioteka ułatwiajaca mapowanie obiektu na inny obiekt. Przydaje sie to głównie w transformacji z encji na DTO. Samo mapowanie po skonfigurowaniu wyglada tak:
User testUser = new testUser(); UserDTO testUserDTO = Mapper.Map<User, UserDTO>(testUser);Jak widać miło, łatwo i przyjemnie. Teraz pare słów o konfiguracji. Zacznijmy od stworzenia profilu czyli klasy ktora posiada informacje w jaki sposob mapowac te obiekty. Wyglada ona tak:
public class DefaultProfile : Profile { public override string ProfileName { get { return "DefaultProfile"; } } protected override void Configure() { // tutaj konfigurujemy typy // Przyklad z User na UserDTO Mapper.CreateMap<User, UserDTO>() .ForMember(dest => dest.Id, opt => opt.MapFrom(src => src.Id)) //podalem tylko pierwsze pole ale reszta analogicznie } }Następnie musimy utworzyć Bootstrapper task który będzie nam ta konfiguracje wczytywał na początku:
public class AutoMapperConfiguratorTask : BootstrapperTask { protected override TaskContinuation ExecuteCore(IServiceLocator serviceLocator) { Mapper.Initialize(x => x.AddProfile<DefaultProfile>()); return TaskContinuation.Continue; } }
I już mamy skonfigurowanego automappera. Jest to bardzo przydatna biblioteczka ułatwiająca życie. Oprócz tych głównych zmian co opisałem we wpisie. Dodałem prosta usługę związana z użytkownikami i odpowiednio zmodyfikowałem kontrolery i widoki. Wiec już proste logowanie działa.
Brak komentarzy:
Prześlij komentarz