Зачем мне использовать переходный атрибут для представления производного свойства только для чтения в основных данных? - PullRequest
Новая
       14

Зачем мне использовать переходный атрибут для представления производного свойства только для чтения в основных данных?

8 голосов
/ 31 октября 2011

Есть ли какая-либо причина для моделирования переходного атрибута для производного свойства, если оно доступно только для чтения?Кажется, намного проще просто объявить свойство в моем настроенном классе, а затем вычислить значение в методе get на лету.Я бы сочетал это с keyPathsForValuesAffecting, чтобы информировать наблюдателей об изменениях.Если бы мне нужно было кэшировать, я бы просто добавил ivar для свойства и сбрасывал его всякий раз, когда изменяется одно из базовых значений (как предложено в ответе на этот вопрос).какие преимущества в моделировании этого как переходного атрибута?

1 Ответ

7 голосов
/ 19 января 2012

Я действительно делал именно эту вещь, из-за этой цитаты из Руководства по программированию основных данных: «Рассмотрим приложение, в котором у вас есть сущность Person с атрибутами firstName и lastName и производное свойство для кэшированных переходных процессов, fullName».Вот где, я полагаю, мне пришла в голову мысль, что это было бы неплохо.

Однако , как говорится далее "(на практике может быть маловероятно, что fullNameатрибут был бы кэширован, но пример легко понять). ", давая мне знать, что это действительно было только для примера того, что они описывали, но, вероятно, не очень хорошая реализация.

Итак, после прочтения больше о переходных процессахсвойства и их предполагаемое использование, я понял, что это, вероятно, плохой способ их использования.Я не получаю никакой выгоды от того, что это кэшируется для моей реализации.Мне очень понравилась возможность использовать точечную нотацию (потому что это свойство) вместо того, чтобы отправлять сообщение объекту, но я не верю, что при его использовании повышается производительность.

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

Итак, я буду рефакторинг своего приложения, чтобы теперь создавать эти простые методы экземпляра на подчиненном-класс для моего объекта managedObject и просто возвращаю результаты, так как я не вижу реальной пользы в том, чтобы сделать их переходными свойствами.

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

По крайней мере, это мое понимание того, как все это работает.Комментарии очень приветствуются, если я что-то неправильно понял, так как это меня очень смущает.

...