DTO vs VM - использовать или не использовать?

Question

В проекте asp.net (webapi + mvc) у меня есть много dto как публичные интерфейсы для моего BLL. Кроме того, большинство моих моделей просмотра одинаковы для соответствующих dtos.

Умные книги говорят нам, что мы должны отделить такие модели, но в проекте я не вижу преимуществ этого решения. Только сотни бесполезных кодов со многими глупыми ошибками.

Итак - правильно ли использовать DTO в качестве модели просмотра, где это возможно? Каковы положительные и отрицательные последствия этого решения?

Answer 1

Объект передачи данных - это всего лишь подмножество или надмножество данных, подлежащих передаче между логическими и физическими границами. Они не могут обеспечить поведение . Это всего лишь данные.

На противоположной стороне модель представления представляет собой сочетание данных и поведения, поскольку они являются логической стороной данного вида.

Поскольку DTO и VM - это шаблоны, которые охватывают различные варианты использования, вы можете в итоге бесполезно использовать данные и поведение, и вы можете добавлять нежелательные зависимости.

Например, DTO может использоваться как в доменах, так и в приложениях. Если вы используете обе концепции DTO и VM, реализованные в одном классе, вы можете заставить проект домена добавить ссылку на библиотеку пользовательского интерфейса, чтобы иметь возможность ее создавать. Я бы избегал этого как можно больше.

Кроме того, вы знаете, есть объектно-ориентированная концепция называется наследование, который может помочь вам здесь, чтобы остаться DRY (не повторяй себя):

public class Base {} 

public class Dto : Base {} 
public class ViewModel : Base {} 

Таким образом, вы можете делиться тем, что является общим для обоих DTO, и просматривать модели с наследованием и избегать повторения кода.

Answer 2

Thx to Matías Fidemraizer за подробный ответ. В дополнение к этому я нашел несколько практических и необходимых приложений.

В случае использования виртуальной машины в качестве отдельного объекта вы добавляете дополнительную точку гибкости. Наиболее распространенным случаем является небольшой изменяющийся формат и/или структура внешних данных. Второй случай. Ваша виртуальная машина может составлять информацию из нескольких объектов DTO, поэтому вы можете оставить свой код bll без каких-либо изменений или свести к минимуму их. Вот как S.O.L.I.D. работает.

Но наиболее полезной частью является модульное тестирование. вы можете проверить свой bll намного проще, потому что ваши объекты DTO могут быть простыми и понятными. Вы также не должны ошибаться в картографических ошибках.