2009-09-16 15 views

Odpowiedz

71

Służą do podobnego celu (enkapsulacji danych dla innej warstwy aplikacji), ale robią to inaczej iz różnych powodów.

  • Zadaniem DTO jest zmniejszenie liczby połączeń między szczeblami aplikacji, zwłaszcza gdy te połączenia są kosztowne (na przykład systemy rozproszone). DTO prawie zawsze są trywializowalne i prawie nigdy nie zawierają żadnych zachowań.

    Na przykład tworzysz witrynę e-commerce. CreateCustomer isą oddzielnymi operacjami na poziomie bazy danych, ale z przyczyn związanych z wydajnością możesz chcieć zebrać ich dane w postaci NewCustomerWithAddressDto, tak aby Twój klient musiał wykonać tylko jeden cykl podróży do serwera i nie musi przejmować się tym, że serwer może robić wiele różnych rzeczy z paczką danych.

  • Termin "ViewModel" oznacza nieco inne rzeczy w różnych smakach MV *, ale jego celem jest głównie rozdzielenie obaw. Twój model jest często zoptymalizowany do celów innych niż prezentacja, a zadaniem ViewModel jest oddzielenie widoku od szczegółów implementacyjnych modelu. Ponadto, większość wzorców MV * zaleca, aby Twoje Widoki były jak najbardziej "głupie", więc ViewModel czasami bierze odpowiedzialność za logikę prezentacji.

    Na przykład w tej samej aplikacji e-commerce Twój CustomerModel jest nieprawidłowym "kształtem" do prezentacji w widoku "Nowy klient". Na początek, Twój widok ma dwa pola formularza dla użytkownika, aby wprowadzić i potwierdzić swoje hasło, a twój CustomerModel nie zawiera w ogóle pola hasła! Twój NewCustomerViewModel będzie zawierał te pola i może, w zależności od twojego smaku MV *, być odpowiedzialny za niektóre logiki prezentacji (na przykład pokazywać/ukrywać części widoku) i podstawową walidację (np. Upewniając się, że oba pola pasują do siebie).

+0

To doskonałe wyjaśnienie! Do tej pory jedyne modele widoków, które widziałem, miały tylko chwytaczy i seterów, więc pomyślałem: wow, to tak dużo jak DTO. Dziękuję za wyjaśnienie tego. – mkelley33

11

Celem jest inna:

  • DTO są używane do przesyłania danych
  • ViewModels służą do wyświetlania danych do użytkownika końcowego.

Zwykle ViewModels zawiera dane prezentacji, które w wielu przypadkach są podobne do tego, co jest w DTO, ale z pewnymi różnicami. Pomyśl o reprezentacji wyliczeń, lokalizacji, waluty, formatów daty, .... Jest tak dlatego, że zwykle nie powinno być żadnych logicznych poglądów.

10

DTOs w MVVM i MVP są zwykle Bardzo Dumb Przedmioty i są w zasadzie tylko kilka ustawiaczy własności i pochłaniacze. Z kolei ViewModels może mieć pewne zachowanie.

Praktycznym pozytywnym efektem ubocznym posiadania DTO jest umożliwienie łatwiejszej serializacji. Jeśli masz raczej skomplikowany obiekt, powiedzmy C#, często będziesz musiał selektywnie wyłączać obiekty, których nie chcesz serializować. Może to być dość brzydkie, a DTO upraszczają ten proces.

+3

+1, kluczową różnicą jest to, że DTO są głupie (a zatem trywialnie serializowalne, co jest ich * zadaniem *), a ViewModels może zawierać logikę, która w przeciwnym razie zagościłaby w twoim widoku (co jest * ich * zadaniem). –

+0

@Igor Zevaka Czy możesz wyjaśnić, co masz na myśli przez zachowanie? –

1

Widok Model i obiekt przenoszenia danych ma podobieństwa i różnice.

podobne: Przesyłanie danych w rekordzie (instancji obiektu, być może w odcinkach) do odbiornika, czy widoku lub usługi

Różnica: Widok modelu ma być wysłany do widoku, w którym to zostanie wyświetlony z formatowaniem. Model widoku również wysyła dane do kontrolera. DTO zazwyczaj nie jest przeznaczony do prezentacji. Jest przeznaczony do wysyłania nieprzetworzonych danych.

Powiązane problemy