DTO = ViewModel?

Я використовую NHibernate для збереження об'єктів домену. Щоб зробити все просто, я використовую проект ASP.NET MVC як мій презентаційний рівень, так і мій рівень обслуговування.

Я хочу повернути свої доменні об’єкти в XML з моїх класів контролерів. Прочитавши декілька публікацій на темі стека переповнення, я збираю ЗНО - це шлях. Однак я також натрапив на повідомлення про ViewModel.

Моє запитання: чи об’єкти передачі даних та ViewModels те саме? Або ViewModel є своєрідним піддіаграмою DTO?

Канонічне визначення DTO - це форма даних об'єкта без будь-якої поведінки.

ViewModels - модель перегляду. ViewModels, як правило, є повними або частковими даними від одного або декількох об'єктів (або DTO), а також будь-яких додаткових членів, характерних для поведінки перегляду (методи, які можуть бути виконані переглядом, властивості вказувати, як змінювати елементи перегляду тощо). Ви можете подивитися на модель перегляду як на всі дані для перегляду плюс поведінку. ViewModels може або не може позначати один на один бізнес-об’єкти або DTO.

До речі, прогнози NHibernate стануть корисними, якщо певному моделю перегляду потрібна підмножина даних із збереженого об'єкта.

ViewModel в ASP.NET MVC практика така ж, як і DTO, однак ViewModel в MVVM-схемі відрізняється від DTO, оскільки ViewModel в MVVM має поведінку, але DTO не має.

DTO! = ViewModel

У шаблоні MVVM ViewModel використовується для ізоляції моделі від подання. Щоб представити модель, ви можете використовувати прості класи DTO , які знову відображаються в базі даних, наприклад, NHibernate. Але я ніколи не бачив клас ViewModel, який моделюється як DTO. Класи ViewModel здебільшого мають поведінку, якої немає у DTO.

DTO - Об'єкти передачі даних - це як саме сказано, контейнери для передачі даних. У них немає поведінки, а лише купа сетерів та жителів. Деякі люди роблять їх непорушними і просто створюють нові, коли потрібно, а не оновлюють існуючі. Вони повинні бути серіалізаційними, щоб дозволити передачу через провід.

Як правило, DTO використовуються для передачі даних від одного шару до іншого рівня через межі процесу, оскільки виклики на віддалену службу можуть бути дорогими, тому всі необхідні дані висуваються в DTO і передаються клієнту за один шматок (грубозернистий).

Однак деякі люди використовують поняття DTO, пов'язані з екраном (нічого спільного з перетином меж процесу). Знову вони заповнюються необхідними даними (як правило, дані, необхідні для певного екрану і можуть бути агрегацією даних з різних джерел) і надсилаються клієнту.

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

У простих випадках, як уже було зазначено, цей DTO може використовуватися для прив'язки до представлення даних, але в більш складних випадках вимагатиме створення ViewModel та вивантаження даних з DTO в ViewModel, що, очевидно, більше роботи (при застосуванні шаблону MVVM) .

Отже знову, як уже було заявлено DTO! = ViewModel

і

DTO і ViewModel мають різні цілі в житті

По-перше, основна відмінність полягає в тому, що ViewModel може мати поведінку або методи, яких DTO MUST NOT !!!

По-друге, використовуючи DTO в якості ViewModel в ASP.NET MVC, ваш додаток буде щільно пов'язане з DTO, і це точно протилежна мета використання DTO. Якщо ви так зробите, яка різниця у використанні моделі вашого домену або DTO, більш складнощі для отримання антидіаграми?

Також ViewModel в ASP.NET може використовувати DataAnnotations для перевірки.

Один і той же DTO може мати різні ViewModels Mapping, а One ViewModel може складатися з різних DTO (завжди з об'єктом відображення, а не зі складом). тому що я думаю, що це ще гірше, якщо у вас є ViewModel, який містить DTO, у нас буде та сама проблема.

З вашого шару презентації, подумайте про DTO як про контракт, ви отримаєте об'єкт, який ви повинні вважати стороннім для вашої програми та не маєте над ним ніякого контролю (навіть якщо у вас колишні сервісні, dto та презентаційні шари ваші).

Нарешті, якщо ви зробите це чисте розділення, розробники можуть працювати разом з легкістю. Людині, яка розробляє ViewModels, Views та Controllers, не потрібно турбуватися про рівень обслуговування чи реалізацію DTO, оскільки він зробить відображення, коли інші розробники закінчать свою реалізацію ... Він навіть може використовувати інструмент Mocking або ручний глузування для заповнення презентаційний шар з даними для тесту.

Для деяких простих подань я буду використовувати свій DTO в якості своїх моделей, але в міру того, як представлення стануть складнішими, я створюю ViewModels.

Для мене це баланс між швидкістю (використання DTO, оскільки я вже маю їх) та гнучкістю (створення ViewModels означає більше роз'єднання проблем).

Якщо ви будете використовувати DTO як ViewModel, це означає, що ви робите велику залежність від DTO через певну причину зміни DTO, це може вплинути на ViewModel.

Краще використовувати DTO і перетворити в viewmodel.

Ми можемо використовувати DTOтакий же, як клас Model, і ми можемо використовувати viewmodel, коли нам потрібно показати / використовувати декілька моделей даних / властивості в одному представленні. Приклад: Спершу я створюю деяку модель, використовуючи базову базу даних сутності. Отже, тепер усі моделі генеруються на базі бази даних. і тепер нам потрібна анотація даних, для цих анотацій даних ми можемо створити ім'я папки DTO. У цій папці DTO ми можемо тримати всі моделі точними, які вже генерують та додають анотацію даних над властивістю. Тоді ми можемо використовувати будь-яку операцію (використовувати контролер, представлення даних), використовуючи ці класи DTO. І коли нам потрібен складний вигляд, я маю на увазі, коли нам потрібні дані кількох класів в одному представленні, ми можемо використовувати viewmodel. Для viewmodel ми можемо створити ім'я папки viewmodel, потім створити спеціальний клас і зберегти це властивість, яке нам потрібно. Я намагався очистити себе. Будь-яка пропозиція високо оцінена.