Модель просмотра мы проверяем на равенство в установщиках, или просто устанавливаем и уведомляем всегда? - PullRequest
1 голос
/ 20 июня 2011

Мне не удалось найти дискуссию на эту тему, но я думаю, что она довольно важна, поэтому есть большой шанс, что она существует, поэтому я буду рад прочитать.

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

Хотя эта проверка выглядит приятной, поскольку она экономит некоторые ресурсы, когда «обновление» на ВМ не вызывает перерисовку View, она также может представлять некоторые плохие эффекты, когда View немного сложнее и имеет некоторый код, который либо не может быть положить в ВМ или при помещении в ВМ слишком сложно по сравнению с оставлением в View.

Так что, как правило, из моего опыта работы с MVVM я могу вспомнить сценарий, когда эта проверка не позволяла некоторому коду работать должным образом. Так что в настоящее время я думаю, что эта проверка является опасной вещью и, как правило, иногда не стоит воспользоваться преимуществом экономии.

Также иногда эту проверку можно использовать в качестве замены для лучшей логики программы, когда, например, в ВМ есть 2 свойства, которые на самом деле тесно связаны, например, представление строки или объекта некоторой сущности. Поэтому, когда задано, например, значение string, внутри него также вызывается установщик объектов, если он проверен правильно, и эта проверка на равенство спасает ситуацию от бесконечного цикла установщиков строк <->, но в этом случае я думаю, что гораздо лучше ввести флаг это проверяется в установщике и не вызывает другого, если это не нужно, когда вызов сказать, что установщик объекта произошел из обращения к установщику строк.

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

Так, как мы должны кодировать наши сеттеры?

Редактировать: хорошо, просто чтобы дать сценарий, самый простой и самый глупый был бы такой: если у нас есть привязка OneWay к View из ВМ и по какой-то причине в коде View есть какой-то обработчик, который изменяет View напрямую, вызывая его чтобы не синхронизироваться с ВМ, обновление ВМ не поможет. Конечно, очевидно, что в этом случае мы должны вызывать VM setter, который связан, но я думаю, что в некоторых случаях сценарий может быть более сложным и продвинутым, когда разрешение становится менее прозрачным. Таким образом, сценарий глуп, но наличие проверки помешает правильному поведению. Я больше думаю о примере из реального мира, где его не так легко решить, но, вероятно, потребуется некоторое время ..

Ответы [ 2 ]

2 голосов
/ 20 июня 2011

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

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

0 голосов
/ 20 июня 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...