Witam
Chciałem się zapytać trochę bardziej doświadczonych czy w swoich projektach są w stanie pogodzić MVC z wykorzystaniem jakiegoś ORM-a np. NHibernate. Jak wiemy Model przechowuje model danych czyli np. klasy. Podobnie jest w ORM gdzie tabele są konwertowane na obiekty. Czy je można zawrzeć w Modelu wzorca ( MVC ) czy nie ? Moim zdaniem nie winno się tak robić bo w MVC tworzenie zwyklych klas różni się troche od świata relacyjnego.
Pozdrawiam
czy w swoich projektach są w stanie pogodzić MVC z wykorzystaniem jakiegoś ORM-a np. NHibernate.
Jak najbardziej. Powiedziałbym, że wykorzystanie dobrego mappera przy stosowaniu wzorca MVC jest bardzo pożądane. Dalszej części posta za bardzo nie rozumiem.
Model przechowuje model danych czyli np. klasy.
Najczęściej sam jest klasą. Może oczywiście mieć w sobie inne encje.
Podobnie jest w ORM gdzie tabele są konwertowane na obiekty.
Nie tabele i nawet nie zawsze pojedyncze rekordy. To co i z czego powstanie opisuje mapowanie.
Przykro mi, ale nie pojąłem twojego problemu. Model w obu ujęciach (MVC i ORM) to dość abstrakcyjne pojęcia, nie muszą to być identyczne obiekty.
I tak już dużo napisałeś i trafiłeś w sedno. Czy masz może linki z jakimiś przykładami z mieszaniną MVC + ORM bo niestety jak wpisuje w google to wyskakuje albo ORM albo MVC i lipa... Chciałbym zobaczyć jak to wygląda w praktyce.
Zobacz sobie źródło jakiegoś większego projektu OpenSource'owego, np. NopCommerce.
Model w MVC to szerokie pojęcie, tzn może to być klasa biznesowa (która często jest encją ORM'owską, ale wcale nie musi nią być).
Generalnie jednak, często stosuje się zasadę, że klasy biznesowe/encje nie są bezpośrednio wystawiane do warstwy odpowiedzialnej za prezentację.
A tworzone są obiekty-kontenery (ViewModels) na dane które są już gotowe do tego, aby przedstawić je w widoku.
Np. Jeżeli masz obiekt domeny
public class Order {
[... tutaj dużo jakiś właściwości]
public List<OrderLine> OrderPositions {get;set;}
public OrderDetails OrderDetails {get;set;}
}
to jeżeli chcemy do widoku przesłać tylko jakiś podzbiór tego obiektu, wykonujemy mapowanie na pobranym obiekcie domeny (ręcznie, lub automatycznie np z użyciem AutoMappera) w kontrolerze.
Wtedy przykładowy ViewModel jest następujący:
public class OrderViewModel {
[.. mniejsza ilosc wlasciwosci ..] { get;set; }
public string OrderDetailsJakisDetal1 {get;set;}
public string OrderDetailsJakisDetal2 {get;set;}
}
Czyli tak naprawdę nie ma wielkiego zamieszania przy pracy ORM-a ze wzorcem MVC. MVC zawiera Model, który jak sam napisałeś jest encją ORM-a ( zakładamy ) i traktujemy go jak zwykły model lecz aby zaprezentować go w widoku musimy użyć Mappera o którym właśnie czytam i owe mapowanie musi odbyć się w kontrolerze.
Zazwyczaj używanie encji ORM jako modeli w MVC się nie sprawdza (bo np. widok potrzebuje różnych dodatkowych danych, których encja nie posiada). Poza tym aplikacja MVC może w ogóle nie mieć pojęcia o żadnych encjach, bo może np. korzystać z warstwy usług WCF zajmujących się obsługą warstwy danych. Wtedy do MVC nigdy nie dotrą encje, co najwyżej DataContracty czy inne DTO.
Mappera po pierwsze nie trzeba używać, po drugie mapowanie nie musi się odbywać w kontrolerze. (A po trzecie, jeśli chodzi o AutoMapper, to jest zwyczajnie do d**y, ale to tak na marginesie.)
Właśnie pisze sobie "prosty" organizer i chcę go napisać zgodnie ze sztuką. Mam do czynienia z 10 tabelami ( zapisuje sobie co i kiedy robiłem, co będzie, co się wydarzy ). Profesjonalista jakby to budował? Jakie wzorce i jakie inne narzędzia typu ORM.
Jest tyle możliwości ładnego napisana aplikacji że już się gubię czy MVC + ORM czy to albo to i koniec :) Jak ORM to na pewno na początek zdecyduje się na Simple Data.
Mapowanie nie musi odbywac sie w kontrolerze ale jezeli mapujemy jakis obiekt na inny obiekt ktory bedzie przedstawiony w widoku, to zasada jest taka, ze musi on byc mapowany w tej samej warstwie, a nie np w warstwie biznesowej, czy dostepu do danych, ktore powinny byc niezalezne.