Макет приложения какао с Core Data и большим количеством бизнес-логики

Question

Для тех, кто видел мои другие вопросы: я делаю успехи, но я еще не обдумал этот аспект.Я перелистывал ответы на вопросы stackoverflow и сайты, такие как Cocoa With Love, но я не нашел подходящий макет приложения (почему такое отсутствие примеров научных или бизнес-приложений? Примеры рецептов и книг слишком упрощены).

У меня есть приложение для анализа данных, которое выглядит следующим образом:

Communication Manager (singleton, управляет оборудованием)DataController (сообщает Comm.mgr, что делать, и проверяет необработанные данные, которые он получает)Модель (получает данные от контроллера данных, очищает, анализирует и сохраняет их)MainViewController (скелет прямо сейчас, слушает comm.mgr для представления представлений и предупреждений)

Теперь, мои данные никогда не будут напрямую отображаться в представлении (как простая таблица сущностей и атрибутов), я, вероятно,использовать основной график для анализа результатов анализа (как только я это выясню).Сохраненные необработанные данные будут огромными (10000 точек), и я использую вектор c ++, обернутый в класс ObjC ++ для доступа к нему.Класс векторов также имеет функции encodeWithCoder и initWithCoder, которые используют NSData в качестве транспорта для вектора.Я пытаюсь следовать надлежащим методам проектирования, но я заблудился о том, как добавить постоянное хранилище в мое приложение (которое потребуется для хранения и просмотра старых наборов данных).

Я прочитал несколько источниковговорят, что «бизнес-логика» должна войти в модельный класс.Вот как у меня это сейчас получается, я отправляю им необработанные данные, и он анализирует, очищает и анализирует результаты, а затем сохраняет их в массивах ivar (векторного класса).Тем не менее, я еще не видел пример Core Data, в котором есть управляемый объект, который является чем-то иным, чем простым хранилищем базовых атрибутов (строк, дат), и у них никогда нет бизнес-логики.Поэтому мне интересно, как я могу объединить эти два аспекта?Должен ли весь мой анализ идти в контроллер данных и управлять им в контексте объекта?Если так, где моя модель?(кажется, нарушает архитектуру MVC, если мои данные хранятся в моем контроллере - прочитайте: поскольку это векторные массивы, я не могу постоянно кодировать и декодировать их в потоки NSData, им нужно место для существования, прежде чем я сохраню их на дискс базовыми данными, и им нужно место для существования после того, как я извлечу их из хранилища и расшифрую их для проверки).

Любые предложения будут полезны (даже в отношении макета, который я уже начал).Я просто нарисовал некоторые связи между объектами, чтобы дать вам представление.Кроме того, у меня пока нет никаких связей между моделью и контроллерами вида / вида (сейчас используется NSLog).

Answer 1

Хотя vector <> отлично подходит для обработки данных, которые вы отбираете (поскольку он поддерживает динамическое изменение размера основного хранилища), вы можете обнаружить, что прямые массивы C достаточны (даже лучше) для уже сохраненных данных. Это добавляет уровень сложности, но позволяет избежать копирования для массивов данных, которые уже имеют известный и статический размер.

NSData -bytes возвращает указатель на необработанные данные в объекте NSData. Базовые данные поддерживают NSData как один из его типов атрибутов. Если вы знаете размер каждого элемента данных, вы можете использовать -length для расчета количества элементов и т. Д.

Что касается выборки, я бы предложил использовать вектор <> для сбора данных, периодически копировать данные в атрибут NSData и сохранять. Примечание: у меня возникла небольшая проблема с этим подходом ( усеченные базовые данные NSData объектов ), который я приписываю базовым данным, не распознавая изменения, внесенные в атрибут NSData, когда он поддерживается объектом NSMutableData и этим изменяемым объектом данные изменены.

Что касается вопроса MVC. Я бы предположил, что данные (модель) управляются с помощью модели. Представления и контроллеры могут запрашивать у модели данные (или подмножества данных) для отображения. Но право собственности на данные зависит от модели. В моем случае, который может быть похож на ваш, были случаи, когда Модель возвращала сокращенные наборы данных (используя алгоритм Дугласа-Пекера). Представления и контроллеры не были тем мудрее, что отбрасывались точки - даже если их запросы к Модели могли сыграть в этом свою роль (коэффициенты масштабирования графика и т. Д.).

Обновление

Вот фрагмент кода из моего класса Data, который расширяет NSManagedObject. Для решения файловой системы, NSFileHandle's -writeData: и методы для мониторинга смещения файла могли бы позволить подобные (лучшие) средства управления.

// Exposed interface for adding data point to stored data
- (void) addDatum:(double_t)datum
    {
    [self addToCache:datum];
    }

- (void) addToCache:(double_t)datum
    {
    if (cache == nil)
        {
        //  This is temporary. Ideally, cache is separate from main store, but
        //  is appended to main store periodically - and then cleared for reuse. 
        cache = [NSMutableData dataWithData:[self dataSet]];
        [cache retain];
        }
    [cache appendBytes:&datum length:sizeof(double_t)];
    //  Periodic copying of cache to dataSet could happen here...
    }

// Called at end of sampling.
- (void) wrapup
    {
    [self setDataSet:[NSData dataWithData:cache]];  // force a copy to alert Core Data of change
    [cache release];
    cache = nil;
    }

Answer 2

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

Первая - это базовая база данных, такая как SQLite, PostgreSQL или любое другое число.решения.Они предназначены для хранения данных и их извлечения;нет логики, поэтому вам нужно выяснить, как управлять таблицами и т. д. Иногда это немного сложно, но они очень эффективны.Они лучше всего справляются с большим количеством данных в необработанном виде;если вам нужны объекты с этими данными, вы должны сами создавать их и управлять ими.

Тогда у вас есть что-то вроде Core Data, которое не должно рассматриваться как база данных, а является структурой «персистентности объекта».С помощью Core Data вы создаете объекты, сохраняете их, а затем извлекаете их как объекты.Это отлично подходит для приложений, в которых у вас есть большое количество объектов, каждый из которых содержит несколько фрагментов данных и отношений с другими объектами.

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

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

РЕДАКТИРОВАТЬ: Кроме того, если вы хотите больше узнать о базовых данных, якак эта книга .Он объясняет всю концепцию object-persistence-vs-database намного лучше, чем я.