Еще один вопрос MVVM … мое понимание корректен?
Извините, если это - дубликат, Это не так, 'Что является MVVM', хотя, а скорее, 'Этот MVVM', я читал вполне немного и думаю, что у меня есть основное понимание того, каково это, у меня есть своя собственная 'острота', как таковая, о том, как я интерпретирую его, но хочу удостовериться, что это корректно, прежде чем я твердо внушу его в голове,
По существу; Модель является чистыми данными - никакие методы, существует один ViewModel на Модель, это содержит ссылку на Модель - это выполняет все изменения в данных Моделей, и наконец Представление будет содержать один (или больше) ссылка (ссылки) ViewModel и формат и отображать данные, обеспеченные ViewModel.
(Не после ссылок на учебные руководства, блоги и т.д., просто a да, или не с тонкими настройками будут прекрасны, поскольку я должен буду перечитать все снова так или иначе если нет :))
5 ответов
Не полностью - по крайней мере, не так, как я бы полностью это определил.
Модель не обязательно должна быть чистыми данными. Модель - это часть вашего приложения, которая полностью зависит от предметной области и не содержит информации, связанной с представлением.
Это обычно включает все данные, относящиеся к предметной области, но также потенциально методы, которые представляют собой чистую бизнес-логику, доступ к данным и т. Д. Все, что относится к бизнес-логике и процессам и не является частью «отображения», является частью модели.
Кроме того, хотя «одна ViewModel на модель» является наиболее распространенной формой работы, бывают случаи, когда вы можете раскрыть «модельный» класс через несколько ViewModels. Это может быть полезно, например, если вы пытаетесь предоставить вашему дизайнеру только часть модели, поскольку это позволяет вам сделать класс ViewModel меньшего размера. ViewModel адаптирует модель для работы с View - если вся Модель не требуется, этот адаптер можно сделать меньше (и легче тестировать, поддерживать и т. Д.), Работая только с необходимой частью.
Лично я предпочитаю думать в терминах «одна ViewModel на View», поскольку ViewModel может адаптировать одну или несколько моделей для надлежащей работы с данным View, но даже в этом случае иногда бывает полезно заменить ViewModel в том же представлении для изменения содержимого.
Близко, но не совсем. Вот некоторые моменты, которые отличаются от ваших:
Модели могут содержать методы. Они не являются просто данными. У них могут быть такие методы, как "retrieve", "store" и т.д. Код бизнес-логики. View agnostic.
Нет ограничений на то, сколько ViewModels хранят ссылку на модель. ViewModels инкапсулируют поведение на уровне представления, поэтому у вас может быть много различных наборов поведения для одной и той же модели. Например, одна ViewModel может быть преобразованием элемента модели только для чтения. Другая может обеспечивать проверку формы на чтение/запись для того же элемента модели.
Для каждого представления может быть более одной ViewModel, в зависимости от того, какое поведение вы хотите получить. Например, вы можете включить поведение "премиум-контента" с одной ViewModel и поведение "бесплатного контента" с другой ViewModel, но сохранить одно и то же представление.
По сути, да. Практически нет. Лучшая практика - всегда уменьшать зависимости и разделять обязанности между классами на основе 1: 1, но вы найдете ситуации IRL, в которых не так просто быть пуристом MVC.
Я считаю, что лучше всего сделать все, что в ваших силах, а остальное задокументировать. Не слишком переживайте о чистоте.
Это довольно близко. За исключением того, что неправильно говорить, что Модель - это только чистые данные. Она может и должна содержать методы для выполнения различных сценариев использования.
Здесь много отличной информации, и я думаю, что большинство этих ответов правильные. Я не думаю, что существует какое-то одно конкретное определение, равно как и один конкретный авторитет по этому вопросу. Даже у компании microsoft нет четкого определения по этому вопросу.
Я бы добавил один пункт, который не входит в название MVVM, но является общим для всех реализаций MVVM, с которыми я знаком. Это система сообщений или уведомлений, которая, кажется, всегда связана как платформа для ViewModel. Сообщения просто уведомляют модели представления, когда что-то меняется, что может повлиять на других. Хорошая реализация этой идеи позволяет моделям представлений и представлениям быть независимыми от того, с чем они не связаны напрямую, используя общие сообщения уведомлений.
Преимущество всего паттерна, на мой взгляд, заключается в том, чтобы сделать ваше приложение с модульными, заменяемыми частями с как можно меньшей зависимостью от типа.
На мой взгляд, это действительно недостающая часть, поскольку она обеспечивает те же преимущества / функции, которые вы получаете от отдельной логики контроллера в паттерне MVC.