DTO = ViewModel?

Używam NHibernate do utrwalania obiektów mojej domeny. Aby zachować prostotę, używam projektu ASP.NET MVC jako warstwy prezentacji i warstwy usług.

Chcę zwrócić obiekty domeny w formacie XML z moich klas kontrolerów. Po przeczytaniu kilku postów tutaj w Stack Overflow, doszedłem do wniosku, że DTO jest drogą do zrobienia. Jednak natknąłem się również na posty mówiące o ViewModel.

Moje pytanie: czy obiekty transferu danych i modele widoków to to samo? A może ViewModel jest rodzajem podrzędnego wzorca DTO?

Kanoniczna definicja DTO to kształt danych obiektu bez żadnego zachowania.

ViewModels to model widoku. ViewModels zazwyczaj są pełnymi lub częściowymi danymi z jednego lub większej liczby obiektów (lub DTO) oraz wszelkich dodatkowych elementów członkowskich specyficznych dla zachowania widoku (metody, które mogą być wykonywane przez widok, właściwości wskazujące sposób przełączania elementów widoku itp.). Możesz spojrzeć na model widoku jako wszystkie dane dla widoku plus zachowania. ViewModels mogą, ale nie muszą, mapować jeden do jednego na obiekty biznesowe lub DTO.

Nawiasem mówiąc, projekcje NHibernate przydają się, jeśli określony model widoku potrzebuje podzbioru danych z utrwalonego obiektu.

ViewModel w praktyce ASP.NET MVC jest taka sama jak DTO, jednak ViewModel we wzorcu MVVM różni się od DTO, ponieważ ViewModel w MVVM ma zachowania, ale DTO nie ma.

DTO! = ViewModel

We wzorcu MVVM ViewModel służy do izolowania modelu z widoku. Do reprezentacji Modelu można użyć prostych klas DTO , które są ponownie mapowane do bazy danych przez np. NHibernate. Ale nigdy nie widziałem klasy ViewModel, która jest modelowana jako DTO .. ​​Klasy ViewModel w większości mają zachowanie, którego nie mają DTO.

DTO - Data Transfer Objects są dokładnie tak, jak mówi, kontenerami do przesyłania danych. Nie zachowują się, a jedynie gromada seterów i getterów. Niektórzy ludzie czynią je niezmiennymi i po prostu tworzą nowe w razie potrzeby, zamiast aktualizować istniejące. Powinny być możliwe do serializacji, aby umożliwić transfer przez kabel.

Ogólnie rzecz biorąc, DTO są używane do przesyłania danych z jednej warstwy do drugiej między granicami procesu, ponieważ wywołania zdalnej usługi mogą być kosztowne, więc wszystkie wymagane dane są wypychane do DTO i przesyłane do klienta w jednej porcji (gruboziarnistej).

Jednak niektórzy ludzie używają pojęcia DTO powiązanych z ekranem (nie ma to nic wspólnego z przekraczaniem granic procesu). Ponownie są one wypełniane wymaganymi danymi (zazwyczaj danymi wymaganymi dla określonego ekranu i mogą być agregacją danych z różnych źródeł) i wysyłane do klienta.

http://blog.jpboodhoo.com/CommentView,guid,21fe23e7-e42c-48d8-8871-86e65bcc9a50.aspx

W prostych przypadkach, jak już zostało powiedziane, ten DTO może być użyty do powiązania z widokiem, ale w bardziej złożonych przypadkach wymagałoby to utworzenia ViewModel i wyładowania danych z DTO do ViewModel, co jest oczywiście bardziej pracochłonne (przy zastosowaniu wzorca MVVM) .

Więc znowu, jak już wspomniano, DTO! = ViewModel

i

DTO i ViewModel mają różne cele w życiu

Po pierwsze, główna różnica polega na tym, że ViewModel może mieć zachowanie lub metody, których DTO nie może !!!

Po drugie, użycie DTO jako ViewModel w ASP.NET MVC sprawia, że ​​aplikacja jest ściśle powiązana z DTO, a to jest dokładnie odwrotnym celem korzystania z DTO. Jeśli to zrobisz, jaka jest różnica w używaniu modelu domeny lub DTO, większa złożoność uzyskania anty-wzorca?

Również ViewModel w ASP.NET może używać DataAnnotations do walidacji.

To samo DTO może mieć różne mapowanie modeli widoków, a jeden model widoku może składać się z różnych DTO (zawsze z mapowaniem obiektów, a nie kompozycją). ponieważ myślę, że jest jeszcze gorzej, jeśli masz ViewModel, który zawiera DTO, będziemy mieli ten sam problem.

Z warstwy prezentacji pomyśl o DTO jak o umowie, otrzymasz obiekt, który musisz uznać za obcy dla swojej aplikacji i nie masz nad nim żadnej kontroli (nawet jeśli masz ex the service, warstwy DTO i prezentacji są Twoje).

Wreszcie, jeśli wykonasz tę czystą separację, programiści mogą z łatwością współpracować. Osoba, która projektuje ViewModels, widoki i kontrolery, nie musi martwić się o warstwę usług lub implementację DTO, ponieważ wykona mapowanie, gdy inni programiści zakończą implementację ... Może nawet użyć narzędzia Mocking lub ręcznego mockowania do wypełnienia warstwa prezentacji z danymi do testu.

W przypadku niektórych prostych widoków użyję mojego DTO jako modeli, ale gdy widoki staną się bardziej złożone, utworzę ViewModels.

Dla mnie to równowaga pomiędzy szybkością (używanie DTO, bo już je mam) a elastycznością (tworzenie ViewModels oznacza większe rozdzielenie obaw).

Jeśli użyjesz DTO jako ViewModel, oznacza to, że uzależniasz się od DTO z jakiegoś powodu, dla którego zmieniasz DTO, może to mieć wpływ na ViewModel.

Lepiej używaj DTO i konwertuj na model widoku.

Możemy użyć tego DTOsamego co klasa Model i możemy użyć viewmodel, gdy potrzebujemy pokazać / użyć danych / właściwości wielu modeli w jednym widoku. Przykład: Najpierw tworzę model, używając bazy danych platformy encji. Więc teraz cały model generuje się na podstawie bazy danych. a teraz potrzebujemy adnotacji danych, dla tych adnotacji danych możemy utworzyć nazwę folderu DTO, W tym folderze DTO możemy zachować dokładność wszystkich modeli, które już generują i dodają adnotację danych nad właściwością. Następnie możemy użyć dowolnej operacji (użyj kontrolera, widoków) używając tych klas DTO. A kiedy potrzebujemy złożonego widoku, mam na myśli, że potrzebujemy danych wielu klas w jednym widoku, możemy użyć viewmodel. W przypadku viewmodel możemy utworzyć nazwę folderu viewmodel, a następnie utworzyć klasę niestandardową i zachować tę właściwość, której potrzebujemy. Próbowałem się oczyścić. Każda sugestia jest wysoko ceniona.