СУХОЙ против безопасности и обслуживания с MVC и View Models

Question

Мне нравится стремиться к СУХОЙ, и, очевидно, это не всегда возможно.Однако мне приходится ломать голову над концепцией, которая кажется довольно распространенной в MVC, - концепцией «модели представления».

Модель представления предназначена для передачи только минимального объема информации длякак безопасность, ремонтопригодность, так и проблемы тестирования.Я понимаю.Это имеет смысл.

Однако, с точки зрения СУХОЙ, View View просто дублирует данные, которые у вас уже есть.Модель представления может быть временной и использоваться только как DTO, но вы в основном поддерживаете две разные версии одной и той же модели, которая, кажется, нарушает принцип DRY.

Модели просмотра нарушают СУХОЙ?Являются ли они необходимым злом?Они приносят больше пользы, чем зла?

Answer 1

Это поднималось снова и снова. Мало того, что это довольно существенный обман, но ответ субъективен и спорен. ViewModels - это ответ на DDD и концепция постоянного невежества.

Сказать, что не использовать ViewModels - это плохо, значит игнорировать то, что Django и Rails и большинство сред PHP ORM / MVC вообще не заботятся об этих концепциях. Вы хотите, чтобы кто-то сказал вам, что все эти другие языки и фреймворки «делают это неправильно?».

То, хотите ли вы использовать ViewModels, на 100% зависит от того, какие архитектурные стили вы собираетесь использовать и каковы цели приложения.

Это все равно что задавать вопрос о том, подходит ли перетаскивание GridViews в приложении WebForm? Зависит от многих вещей.

Существует также неправильное представление о СУХОЙ, что у вас здесь. Прокси-классы из службы WCF нарушают DRY? Содержит ли ViewModel логику? Основная цель СУХОГО состоит в том, чтобы не иметь дублированной логики с осмысленной целью. Не нарушают ли это несколько DTO, которые используют общие объектные формы?

Принцип DDD ограниченного контекста также послужил бы хорошим чтением. Если объект ShoppingCart должен работать по-разному в настройках хранилища и веб-сайта электронной коммерции, значит ли это, что вы должны делиться типами? Что происходит, когда единственной общей функциональностью является общая цена (цена + налог + доставка)? Вы создаете базовый класс только для этого, поэтому увеличивая связь? Каковы компромиссы во времени / стоимости / обслуживании для 100% СУХОГО для простого метода, такого как GetTotal (). Нарушает ли DRY, когда это имеет смысл, уменьшение сложности и общей стоимости обслуживания вашей кодовой базы?

Я прошу прощения за то, что ответил так много вопросов, но, надеюсь, теперь вы можете увидеть нюансы и тонкости вопроса, который вы задали. ,)

Answer 2

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

Я также думаю, что реальная ценность моделей представлений не 'Это обязательно станет очевидным в версии 1.0 вашего приложения.Вы будете благодарны за работу над версией 2.0, когда полностью переосмыслите работу своего бэкэнда, но вам не нужно переносить эти изменения на слой представления.