каково различие между моделью представления и объектом передачи данных?
Если существует шанс, что Вы снова используете этот код, то я, вероятно, приложил бы усилие для движения с объектно-ориентированной перспективой. Используя глобальное пространство имен может быть опасным - Вы рискуете трудно для нахождения ошибок из-за имен переменной, которые снова используются. Обычно я запускаю при помощи объектно-ориентированного подхода для чего-то большего чем простого обратного вызова так, чтобы я не делал вещи перезаписи. Любое время, когда у Вас есть группа связанных функций в JavaScript, я думаю, это - кандидат на объектно-ориентированный подход.
3 ответа
Они служат схожей цели (инкапсуляция данных для другого уровня приложения), но делают это по-другому и по разным причинам.
Целью DTO является уменьшение количества вызовов. между уровнями приложения, особенно когда эти вызовы дороги (например, в распределенных системах). DTO почти всегда тривиально сериализуемы и почти никогда не содержат никакого поведения.
Например, вы разрабатываете сайт электронной коммерции.
CreateCustomerиAddCustomerAddress- это отдельные операции на уровне базы данных, но из соображений производительности вы можете объединить их данные вNewCustomerWithAddressDto, чтобы клиенту нужно было только совершает одно обращение к серверу и не делает этого Не нужно заботиться о том, чтобы сервер мог делать кучу разных вещей с пакетом данных.Термин «ViewModel» означает несколько разные вещи в разных вариантах MV *, но его цель - в основном разделение задач. Ваша модель часто оптимизируется для каких-то целей, отличных от представления, и именно ViewModel несет ответственность за отделение вашего представления от деталей реализации модели. Кроме того, большинство шаблонов MV * советуют делать ваши представления как можно более «тупыми», поэтому ViewModel иногда берет на себя ответственность за логику представления.
Например, в том же приложении электронной коммерции ваша
CustomerModelнеправильная «форма» для презентации в вашем представлении «Новый клиент». Для начинающих, в вашем представлении есть два поля формы для ввода и подтверждения пароля пользователем, а вашаCustomerModelвообще не содержит поля пароля! ВашNewCustomerViewModelбудет содержать эти поля и может, в зависимости от вашего вкуса MV *, отвечать за некоторую логику представления (например, для отображения / скрытия частей представления) и базовую проверку (например, обеспечение того, чтобы оба поля пароля match).
Цель другая:
- DTO используются для передачи данных
- ViewModels используются для отображения данных конечному пользователю.
Так что обычно ViewModels содержат данные презентации, ведь во многих случаях похож на то, что есть в DTO, но с некоторыми отличиями. Подумайте о представлении перечислений, локализации, валюты, форматов даты, .... Это потому, что обычно в вашей точке зрения не должно быть никакой логики.
DTO в MVVM и MVP обычно представляют собой очень тупые объекты и в основном представляют собой просто набор средств установки и получения свойств. ViewModels, с другой стороны, могут иметь некоторое поведение.
Практический положительный побочный эффект наличия DTO - это упрощение сериализации. Если у вас есть довольно сложный объект, скажем, на C #, вам часто приходится выборочно отключать вещи, которые вы не хотите сериализовать. Это может стать довольно уродливым, и DTO упрощают этот процесс.