Core Data + Core Animation / CALayer вместе?

Question

Я делаю приложение Какао с пользовательскими интерфейсами. До сих пор я реализовал одну версию приложения, используя CALayer, выполняющий рендеринг, что было здорово, учитывая иерархическую структуру CALayers, и его функцию [hitTest:] для обработки событий мыши. В этой ранней версии моделью приложения являются мои пользовательские классы.

Однако, по мере роста программы, я чувствую потребность использовать Core Data для модели, не только для простоты управления связыванием / отменой операций, но и для того, чтобы попробовать новую технологию.

Мой метод до сих пор:

В базовых данных: создание блока сущности , с атрибутами xPos, yPos, шириной, высотой ... и т. Д.

Затем создаем класс BlockView: CALayer для рисования, который использует такие методы, как self.position.x = [self valueForKey: @ "xPos"] для извлечения значений от модели.

В этом случае каждый объект BlockView должен также хранить локальную копию xPos , что НЕ хорошо.

У кого-нибудь из вас есть лучшие предложения?

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

Answer 1

Использование Core Data для хранения фактических мест выполнения ваших графических объектов не очень хорошая идея. При этом модель данных напрямую смешивается с представлением. Это усложнит отладку и обслуживание приложения и сделает его компоненты гораздо менее пригодными для повторного использования.

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

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

Answer 2

Является ли редактирование и сохранение позиции и размера этих «блоков» тем заданием, которое существует в вашем приложении?

Если нет, то этой информации, вероятно, не должно быть в вашей модели.

Answer 3

Итак, в вашей реализации каждый BlockView имеет свой собственный x?

Почему бы вашему классу BlockView не содержать ссылку на блок?

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

Это сохраняет хорошее разделение между вашими классами представления и моделью.