Звичайний старий об’єкт CLR проти об'єкта передачі даних

POCO = Простий старий CLR (або краще: Class)

DTO = Об'єкт передачі даних

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

Чи POCO та DTO те саме?

POCO дотримується правил OOP. Він повинен (але не повинен) мати стан та поведінку. POCO походить від POJO, придуманого Мартіном Фаулером [ анекдот тут ]. Він використовував термін POJO як спосіб зробити більш сексуальним відхилення рамкових важких реалізацій EJB. POCO слід використовувати в тому ж контексті в .Net. Не дозволяйте рамкам диктувати дизайн вашого об'єкта.

Єдина мета DTO - передати стан і не повинна мати поведінки. Дивіться пояснення Мартіна Фаулера про перехід до допиту для прикладу використання цієї моделі.

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

Хоча ви можете ставитися до POCO, як DTO, ви ризикуєте створити анемічну модель домену, якщо це зробите. Крім того, існує невідповідність структури, оскільки DTO повинні бути розроблені для передачі даних, а не для відображення справжньої структури бізнес-домену. Результатом цього є те, що DTO, як правило, більш плоскі, ніж ваш фактичний домен.

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

Для мене, мабуть, зайве робити внесок, оскільки я вже заявив про свою позицію у своїй статті в блозі, але останній абзац цієї статті щось резюмує:

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

До речі, Патріку, я читав POCO як статтю про спосіб життя, і я повністю згоден, що це фантастична стаття. Це насправді розділ із книги Джиммі Нілссона, який я рекомендував. Я поняття не мав, що це доступно в Інтернеті. Його книга справді є найкращим джерелом інформації, яку я знайшов про POCO / DTO / Repository / та інших практиках розробки DDD.

POCO - це просто об'єкт, який не приймає залежності від зовнішніх рамок. Це ГРАНІ.

Будь POCO має поведінку чи ні, це не має значення.

DTO може бути POCO, як і доменний об'єкт (який, як правило, багатий на поведінку).

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

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

Я написав статтю на цю тему: DTO vs Value Object vs POCO .

Коротко:

• DTO! = Значення об'єкта
• DTO ⊂ POCO
• Значення об’єкта ⊂ POCO

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

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

Оновлення Мартін Фаулер сказав, що цей підхід є важким шляхом, і його слід застосовувати лише у випадку значної невідповідності між шаром домену та користувальницьким інтерфейсом.

Основний випадок використання DTO - це повернення даних із веб-служби. У цьому випадку POCO і DTO рівнозначні. Будь-яка поведінка в POCO буде видалена при поверненні з веб-сервісу, тож насправді не має значення, чи має вона поведінку.

ось загальне правило: DTO == зло та індикатор переробленого програмного забезпечення. POCO == добре. "Корпоративна" модель знищила мізки багатьох людей у ​​світі Java EE. будь ласка, не повторіть помилку в .NET land.

Класи DTO використовуються для серіалізації / десеріалізації даних з різних джерел. Коли ви хочете десаріалізувати об’єкт з джерела, не має значення, яке це зовнішнє джерело: сервіс, файл, база даних тощо, можливо, ви хочете використовувати лише частину цього, але ви хочете, щоб простий спосіб дезаріалізувати ці дані до об’єкт. після цього ви копіюєте ці дані в XModel, який ви хочете використовувати. Серіалізатор - це прекрасна технологія завантаження об'єктів DTO. Чому? вам потрібно лише одна функція для завантаження (десеріалізації) об'єкта.

TL; DR:

DTO описує схему передачі стану. POCO нічого не описує. Це ще один спосіб сказати "об'єкт" в OOP. Він походить від POJO (Java), придуманого Мартіном Фаулером, який буквально просто описує його як більш фантазійне ім'я для "об'єкта", оскільки "об'єкт" не дуже сексуальний.

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

POCO - це звичайний об'єкт, але те, що мається на увазі під «звичайним», - це те, що він не є особливим. Це просто означає, що це об'єкт CLR, не маючи на увазі малюнок. Родовий термін. Він не створений для роботи з деякими іншими рамками. Так що якщо ваш POCO є[JsonProperty] або прикраси EF, це його властивості, то я б стверджував, що це не POCO.

Ось декілька прикладів різних видів шаблонів об'єктів для порівняння:

• Модель перегляду : використовується для моделювання даних для подання. Зазвичай має примітки до даних для сприяння прив'язці та валідації. У MVVM він також виконує функції контролера. Це більше, ніж DTO
• Об'єкт значення : використовується для представлення значень
• Корегований корінь : використовується для управління державою та інваріантами
• Обробники : використовуються для відповіді на подію / повідомлення
• Атрибути : використовуються як прикраси для вирішення проблем, що перетинаються між собою
• Сервіс : використовується для виконання складних завдань
• Контролер : використовується для управління потоком запитів та відповідей
• Фабрика : використовується для налаштування та / або складання складних об'єктів для використання, коли конструктор недостатньо хороший. Також використовується для прийняття рішень щодо того, які об’єкти потрібно створити під час виконання.
• Сховище / DAO : використовується для доступу до даних

Це все просто об’єкти, але зауважте, що більшість із них, як правило, прив’язані до візерунка. Таким чином, ви можете назвати їх "об'єктами", або ви можете бути більш конкретними щодо його намірів і називати його таким, яким він є. Ось чому ми маємо шаблони дизайну; описати складні поняття в кількох роботах. DTO - зразок. Сукупний корінь - це шаблон, модель перегляду - це візерунок (наприклад, MVC & MVVM). POCO - це не зразок.

POCO не описує шаблону. Це просто інший спосіб посилання на класи / об'єкти в OOP. Розглядайте це як абстрактне поняття; вони можуть посилатися на що завгодно. IMO, є односторонні відносини, хоча оскільки об'єкт досягає точки, коли він може чисто виконувати лише одну мету, це вже не POCO. Наприклад, як тільки ви позначите свій клас прикрасами, щоб він працював з деякими рамками, це вже не POCO. Тому:

• DTO - POCO
• POCO не є DTO
• Модель перегляду - POCO
• POCO - це не модель перегляду

Сенс у розрізненні між ними полягає в тому, щоб чіткі та послідовні зразки дотримувалися зусиль, щоб не перетинати проблеми і не призводити до тісного зв'язку. Наприклад, якщо у вас є бізнес-об'єкт, який має методи мутації стану, але також прикрашений до пекла декораціями EF для збереження на SQL Server AND JsonProperty, щоб він міг бути відправлений назад через кінцеву точку API. Цей об'єкт буде нетерпимим до змін і, ймовірно, буде залитий варіантами властивостей (наприклад, UserId, UserPk, UserKey, UserGuid, де деякі з них позначені так, щоб їх не було збережено в БД, а інші позначені, щоб не бути серіалізованими до JSON в кінцевій точці API).

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

Навіть не називайте їх DTO. Їх називають Моделями .... Період. Моделі ніколи не мають поведінки. Я не знаю, хто придумав цей тупий термін DTO, але це повинно бути .NET річ все, що я можу зрозуміти. Подумайте про перегляд моделей MVC, одна і та сама дамба **, моделі використовуються для передачі стану між шарами сервера або протягом провідного періоду, вони всі моделі. Властивості з даними. Це моделі, по яких ви пропускаєте над дротом. Моделі, моделі моделей. Це воно.

Я хочу, щоб дурний термін DTO відійшов від нашої лексики.