Comments 23
Зачем вообще использовать два набора объектов? Не проще ли обойтись одним?
Это нерукопожато, т.к. это разные сущности, не все свойства DO должны быть записаны в DTO, может возникнуть путаница.
DO объекты и другие серверные могут иметь циклические ссылки, бизнес логику, и вообще плохо поддаются сериализации в лоб. А DTO — это вообще считай структуры, только объявлены как классы. К тому же могут иметь структуру отличную от DO объектов. Структуру удобную для бизнес процессов через API и ничего лишнего. С ними меньше путаницы.
Не спорю, что DO-DTO правильная связка. Однако:
— связка имеет смысл только в случае remote interface, особенно если он публичный. Локальные бизнес процессы неплохо работают напрямую с DO.
— структура DTO, мепящего один и тот же DO, может меняться для разных операций. Приходится писать разные мепперы для одного и того же DO.
— в некоторых случаях приходится писать обратный меппер DTO->DO
— в 90% случаев структура DO и DTO практически идентична (не считая ссылок), а количество полей запросто может достигать нескольких десятков.
— писать и поддерживать меппинги — достаточно нудная и ресурсозатратная задача, если в проекте нет отдельной специально обученной обезьяны, пишущей и тестирующей меппинги. При использовании различных ухищрений и библиотек как правило теряется typesafe, и в разы усложняется поддержка (модификации DO, анализ изменений, тестирование, etc...)
Поэтому в большинстве случаев обходятся одними DO. Обычно любая ORM проксирует ссылки, а при сериализации они не резольвятся. Таким образом можно вручную контролировать возвращаемый подграф. Некоторые ORM позволяют въявную ограничивать список полей для запрашиваемого объекта (остальные либо проксируются для ленивой инициализации, либо тупо устанавливаются в null).
Можно также использовать смешанную схему: DTO, содержащие DO.
P.S. DO не должно иметь бизнес логику, это противоречит идее DO. DO — это такие же структуры, только с connected state.
— связка имеет смысл только в случае remote interface, особенно если он публичный. Локальные бизнес процессы неплохо работают напрямую с DO.
— структура DTO, мепящего один и тот же DO, может меняться для разных операций. Приходится писать разные мепперы для одного и того же DO.
— в некоторых случаях приходится писать обратный меппер DTO->DO
— в 90% случаев структура DO и DTO практически идентична (не считая ссылок), а количество полей запросто может достигать нескольких десятков.
— писать и поддерживать меппинги — достаточно нудная и ресурсозатратная задача, если в проекте нет отдельной специально обученной обезьяны, пишущей и тестирующей меппинги. При использовании различных ухищрений и библиотек как правило теряется typesafe, и в разы усложняется поддержка (модификации DO, анализ изменений, тестирование, etc...)
Поэтому в большинстве случаев обходятся одними DO. Обычно любая ORM проксирует ссылки, а при сериализации они не резольвятся. Таким образом можно вручную контролировать возвращаемый подграф. Некоторые ORM позволяют въявную ограничивать список полей для запрашиваемого объекта (остальные либо проксируются для ленивой инициализации, либо тупо устанавливаются в null).
Можно также использовать смешанную схему: DTO, содержащие DO.
P.S. DO не должно иметь бизнес логику, это противоречит идее DO. DO — это такие же структуры, только с connected state.
С ормами всегда есть нюансы. Самое простое — List в EF. Мапить влоб не очень красиво, а вот отдельная модель уровня хранения данных решает эту проблему. Плюс с теми же Dto можно развесить доп. логику на базовый класс, которая не касается DO.
>>DO не должно иметь бизнес логику, это противоречит идее DO. DO — это такие же структуры, только с connected state.
Кто сказал? Вот к примеру Фаулер сказал, что анемичная доменная модель — анти-паттерн: www.martinfowler.com/bliki/AnemicDomainModel.html
Кто сказал? Вот к примеру Фаулер сказал, что анемичная доменная модель — анти-паттерн: www.martinfowler.com/bliki/AnemicDomainModel.html
Хорошо когда узкое место в перфомансе — AutoMapper, а не кривая архитектура :-).
Идеальная архитетура выглядет как-то так:[/sarcasm]
EmployeePersistenceObj -> EmployeeDomainObj -> EmployeeDto — [transport] — EmployeeDto -> EmployeeClientDomainObj -> EmployeeViewModel
Идеальная архитетура выглядет как-то так:[/sarcasm]
EmployeePersistenceObj -> EmployeeDomainObj -> EmployeeDto — [transport] — EmployeeDto -> EmployeeClientDomainObj -> EmployeeViewModel
PS: говорят EmitMapper хорош, генерит эти штуки сам в рантайме (эмитит IL).
Emit как то пропустил, но синтаксис у него примерно такой же как и AutoMapper'a. А AutoMapper ещё плох том что джуниоры имею тенденцию писать в его правилах бизнес логику.
есть старая хабрастатья со сравнением AutoMapper, BLToolkit и EmitMapper. По той статье EmitMapper рвёт на два порядка! Но статья старая, может, за эти пять лет AutoMapper тоже научился этим заклинаниям…
Очень интересуют ответы на три вопроса:
1. На сколько процентов уменьшилось время выполнения маппинга?
2. Сколько времени в среднем занимает получение DO объекта из бд и отправка DTO объекта в вебсервис
3. Сколько человеко-часов было потрачено на разработку вашего маппинга на Т4 шаблонах?
1. На сколько процентов уменьшилось время выполнения маппинга?
2. Сколько времени в среднем занимает получение DO объекта из бд и отправка DTO объекта в вебсервис
3. Сколько человеко-часов было потрачено на разработку вашего маппинга на Т4 шаблонах?
1. На сколько процентов сейчас не скажу, а абсолютно на 120 миллисекунд насколько я помню по профайлеру. На мало процентов скорее всего, но как я писал это не самое узкое место.
2. В среднем 100-500 миллисекунд.
3. Около месяца работы джуниора под моим руководством,
примерно: джуниор — 160, синьор — 8.
Но работа по оптимизации ведется по всем направлениям, просто тут была возможность что то сделать, отдали её джуниору. И в результате этой работы получился продукт который можно выделить отдельно.
2. В среднем 100-500 миллисекунд.
3. Около месяца работы джуниора под моим руководством,
примерно: джуниор — 160, синьор — 8.
Но работа по оптимизации ведется по всем направлениям, просто тут была возможность что то сделать, отдали её джуниору. И в результате этой работы получился продукт который можно выделить отдельно.
Познавательная вещь. Из плюсов еще можно отметить отсутствие зависимости от мэпперов (AutoMapper, EmitMapper и т.д.).
Возникла идея. А может ли с помощью шаблонов генерить еще и dto классы?
А какие преимущества вашего генератора по сравнению с существующими? Занимались исследованием?
Сейчас погуглил немного и нашел по DTO T4 вот что:
Ну на самом деле из всех мне ваш больше всего понравился.
Сейчас погуглил немного и нашел по DTO T4 вот что:
- github.com/stanshillis/DTOGenerator (только генерация).
- github.com/tomasherceg/dto-gen (генерация и мэппинг, правда у меня не заработало, не стал разбираться).
- github.com/taimila/T4DtoBuilder (генерация строителей для DTO).
- entitiestodtos.codeplex.com (видимо поддержка генерации и мэппинга, не запустилась у меня, видимо поддержка только 2012 студии).
Ну на самом деле из всех мне ваш больше всего понравился.
Честно. мы не искали. Задача простая, мелкая подходит для обучения и к тому же с пользой основному проекту.
Большая куча зайцев одним выстрелом. И нам нужен был маппинг для себя.
А по Вашему списку:
1. Чисто генерация dto по образу и подобию do не интересует. У нас DTO сильно отличается от DO
2. dto-gen — выглядит похоже, но опять генерация dto, похоже без кастомизации и маппинг только на свои объекты.
3. T4DtoBuilder — странный способ использовать method chain вместо object initializer'a
4. entitiestodtos — вообще расширение для студии, стараюсь ставить поменьше.
В общем одним из этих проектов можно сгенерировать DTO, а нашим сгенерировать маппинг, и получится то, что Вы хотите!
Большая куча зайцев одним выстрелом. И нам нужен был маппинг для себя.
А по Вашему списку:
1. Чисто генерация dto по образу и подобию do не интересует. У нас DTO сильно отличается от DO
2. dto-gen — выглядит похоже, но опять генерация dto, похоже без кастомизации и маппинг только на свои объекты.
3. T4DtoBuilder — странный способ использовать method chain вместо object initializer'a
4. entitiestodtos — вообще расширение для студии, стараюсь ставить поменьше.
В общем одним из этих проектов можно сгенерировать DTO, а нашим сгенерировать маппинг, и получится то, что Вы хотите!
а насчёт преимущества, наверно кастомизация, можно сгенерировать метод любой сложности.
А вы проводили замеры по скорости маппинга между прямым копированием объектов, библиотекой AutoMapper и каким-то более быстрым маппером? Если мне не изменяет память, EmitMapper работает в сотни раз быстрее, чем AutoMapper и почти сравним с ручным копированием.
Как я уже писал EmitMapper я пропустил. А с автомаппером есть разница. Чужие обзоры посмотрел потом.
Sign up to leave a comment.
Генерация маппинга через t4 шаблоны