Мы используем метод @Command для запуска любого метода, но мы используем метод @NotifyChange для отражения переменных класса. Но вместо @NotifyChange мы используем
BindUtils.postNotifyChange(null, null, this.class, "*");
Итак, какое утверждение подходит для лучшей производительности.
На самом деле, BindUtils
может быть более мощным, а затем @NotifyChanged
Если вы собираетесь использовать его таким же образом, я не думаю, что существует большая разница в производительности. Единственное большое различие заключается в том, что @NotifyChange
работает только с сеттерами и командами и что BindUtils
можно вызывать из каждого метода.
Теперь, когда будет разница?
Предположим, у вас есть список того, что вы получаете с этим:
public List<User> getUsers() {
return users;
}
Предположим, что у нас есть кнопки рядом с каждым пользователем, и кнопка запускает команду, которая меняет этого пользователя (например, блокирование этого пользователя). Что мы можем сделать, это поместить @notifyChanged("users")
что будет означать в zk, запрашивая getUsers();
Если мы используем BindUtils
мы можем сделать следующее:
BindUtils.postNotifyChanged(null,null,user,"*");
или
BindUtils.postNotifyCHanged(null,null,user,"blocked");
Даже у нас нет получателя для этого пользователя в нашей виртуальной машине, это все равно будет выполнено, и только этот пользователь во всем списке будет обновляться. С первой командой все данные обновляются, а вторая только блокируется. Теперь второе не всегда возможно, возможно, вы не знаете, какое поле или все поля обновлены, но вы обновляете 1 пользователя вместо того, чтобы получать всех пользователей x.
Прежде чем поставить этот вопрос в SO, смотрите здесь:
Возможно ли использовать @NotifyChange вместо BindUtils.postNotifyChange?
Я лично предлагаю использовать определенную переменную вместо "*" И ее не лучше по производительности BindUtils.postNotifyChange(null, null, this.class, "*");
Основное различие между BindUtils
и @NotifyChange
:
BindUtils
просто берет одно свойство, а @NotifyChange
принимает сразу несколько свойств.