Во-первых, основное отличие состоит в том, что ViewModel может иметь поведение или методы, которые DTO не должны !!!
Во-вторых, использование DTO в качестве ViewModel в ASP.NET MVC делает ваше приложение тесно связанным с DTO, а это прямо противоположная цель использования DTO. Если вы это сделаете, какая разница при использовании вашей модели домена или DTO, сложнее получить анти-шаблон?
Также ViewModel в ASP.NET может использовать DataAnnotations для проверки.
Один и тот же DTO может иметь разные сопоставления ViewModels, и одна ViewModel может быть составлена из разных DTO (всегда с сопоставлением объектов, а не композицией). потому что я думаю, что будет еще хуже, если у вас есть ViewModel, содержащий DTO, у нас будет та же проблема.
На уровне представления подумайте о DTO как о контракте, вы получите объект, который вы должны рассматривать как незнакомый для вашего приложения и не имеющий никакого контроля над ним (даже если у вас есть служба, уровни dto и презентации ваши).
Наконец, если вы сделаете это четкое разделение, разработчики смогут легко работать вместе. Человеку, который разрабатывает модели представления, представления и контроллеры, не нужно беспокоиться об уровне обслуживания или реализации DTO, потому что он сделает сопоставление, когда другие разработчики завершат свою реализацию ... Он даже может использовать инструмент Mocking или ручное издевательство для заполнения слой представления с данными для тестирования.