breeze: проверка свойства навигации при изменении

#breeze

#бриз

Вопрос:

У меня есть свойство навигации, к которому я добавил пользовательский валидатор.

Средство проверки срабатывает нормально при сохранении объекта. Однако это не срабатывает при добавлении / удалении объектов из свойства навигации.

Должен ли я подписаться на событие PropertyChanged или есть другой способ справиться с этим?

Кроме того, почему нет события PropertyChanged для каждого свойства вместо того, чтобы подписываться на любое изменение свойств?

Ответ №1:

Существует два вида свойств навигации: скалярные и нескалярные. Скалярное свойство — это что-то вроде ‘Order.Клиент’, когда с заказом связан единственный клиент. Установка или изменение клиента в этом случае вызовет событие entityAspect.PropertyChanged.

Для нескалярного свойства, такого как скажем ‘Customer.Заказы’, доступ к свойству возвращает массив заказов, связанных с клиентом.

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

Однако вы МОЖЕТЕ просмотреть сам массив на предмет изменений, см. Событие arrayChanged в документах breeze Api.

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

Помните, что события уровня свойств объекта, если бы они существовали, должны были бы регистрироваться для стольких объектов, которые находятся в вашем кэше (100 или 1000), что в разы превышает количество свойств ваших объектов (5-50).

Большая часть из того, что описано здесь, является довольно стандартной для отслеживания изменений объектов в ряде сред на различных языках программирования. Мы не пытались изобретать идею заново, а просто повторно внедрили довольно распространенный стандарт.