Asp.net MVC Плюсы и минусы составных DTO против строго типизированной модели + слабо типизированная передача ViewData?

Question

Я пытаюсь выяснить, какие проблемы возникают у каждой стороны при создании DTO, у которого есть выпадающие списки модель + и т. Д. ... против передачи этих дополнительных объектов / списков во ViewData. Я не выдвинул аргумент против использования ViewData, кроме строго типизированного пуриста во мне.

Я подумал, что спросить, что еще мне нужно рассмотреть?

Answer 1

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

Answer 2

Важно мнение Терье о тестируемости.Кроме того, производительность очевидна (без поиска в словаре или приведения).

С другой стороны, ViewData еженедельного типа имитирует мир Rails.В редком случае, когда вам нужно перевести проект из Rails в ASP.NET MVC за очень ограниченное время (что у меня фактически было), это делает процесс более прямым.Что действительно относится к ядру одного Pro для слабо типизированных ViewData: быстрая разработка приложений.

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

Answer 3

Это вопрос инкапсуляции. Я поместил все, что мне нужно для визуализации представления (включая данные выпадающего списка и проверку на стороне сервера) в объект ViewModel. Таким образом, у меня нет вещей, разбросанных по сильным ветрам.

Я не пурист, но идея помещать нетипизированную информацию в ViewData и приводить ее к правильному типу в представлении, мне просто неудобна. Мне еще предстоит найти ситуацию, в которой это имеет смысл, если только я не передаю небольшие фрагменты информации представлению, которое не имеет ничего общего с ViewModel или базовой моделью базы данных.

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