Когато решавате какво постоянство да използвате, важно е да запомните, че Core Data е преди всичко система за управление на обектна графика. Истинската функция е да се създаде слой на модела по време на изпълнение на моделирани приложения за дизайн Model-View-Controller. Устойчивостта всъщност е вторична и дори незадължителна функция на основните данни.
Основните проблеми при моделирането/постоянството са размерът на данните и сложността на данните. И така, относителните силни и слаби страни на всеки тип постоянство биха се разделили по следния начин:
_______________________________
| | |
2 | | |
| SQL | Core Data | 4
s | | |
i |_______________ ______________|
z | | |
e | | |
1 | Collection | Core Data | 3
| plist/xml | |
| | |
-------------------------------
Complexity--->
Към което бихме могли да добавим трето измерение на лизингодателя, променливостта, т.е. колко често се променят данните
(1) Ако размерът, сложността и променливостта на данните са ниски, тогава използването на колекция, напр. NSArray, NSDictionary, NSSet на сериализиран персонализиран обект би бил най-добрият вариант. Колекциите трябва да се четат изцяло в паметта, така че да се ограничи техният ефективен размер на устойчивост. Те нямат управление на сложността и всички промени изискват пренаписване на целия постоянен файл.
(2) Ако размерът е много голям, но сложността е ниска, тогава SQL или друг API за база данни може да даде превъзходна производителност. напр. стара модна библиотечна индексна система. Всяка карта е идентична, картите нямат връзки помежду си и картите нямат поведение. SQL или други процедурни DB са много добри при обработката на големи количества информация с ниска сложност. Ако данните са прости, тогава SQL може да обработва дори силно променливи данни ефективно. Ако потребителският интерфейс е също толкова прост, тогава има малко допълнителни разходи при интегрирането на потребителския интерфейс в обектно-ориентирания дизайн на приложение за iOS/MacOS.
(3) Тъй като данните стават все по-сложни, основните данни бързо стават по-добри. „Управляваната“ част от „управляваните обекти“ управлява сложността на взаимоотношенията и поведението. С колекции или SQL вие управлявате ръчно сложността и може бързо да се окажете затрупани. Всъщност съм виждал хора, които се опитват да управляват сложни данни с SQL, които в крайна сметка пишат свой собствен миниатюрен стек от основни данни. Излишно е да казвам, че когато комбинирате сложност с променливост, Core Data е още по-добър, защото се справя автоматично със страничните ефекти от вмъквания и изтривания.
(Сложността на интерфейса също е проблем. SQL може да обработва голяма, статична отделна таблица, но когато добавите йерархии от таблици, в които може да се променя в движение, SQL се превръща в кошмар. Core Data, NSFetchedResultsController и UITableViewController/делегати го правят тривиално.)
(4) С висока сложност и голям размер Core Data очевидно е най-добрият избор. Основните данни са силно оптимизирани, така че увеличаването на размера на графиката да не затруднява нещата толкова, колкото при SQL. Освен това получавате високо интелигентно кеширане.
Освен това не бъркайте „разбирам напълно SQL, но не и основните данни“ с „основните данни имат високи разходи“. Наистина не е така. Дори когато Core Data не е най-евтиният начин за въвеждане и извеждане на данни от постоянството, неговата интеграция с останалата част от API обикновено дава превъзходни резултати, когато вземете предвид скоростта на разработка и надеждността.
В конкретния случай от описанието не мога да разбера дали сте в случай (2) или случай (4). Зависи от вътрешната сложност на данните И сложността на потребителския интерфейс. Ти каза:
Не мисля, че искам да създам модел на основни данни със 100 обекта и след това да използвам картограф, за да импортирам JSON в него.
Имате предвид действителни абстрактни обекти тук или просто управлявани обекти? Не забравяйте, че обектите са за управляваните обекти, каквито са класовете за екземплярите. Ако първото, тогава да, Core Data ще бъде много работа отпред, ако второто, тогава няма да бъде. Можете да изградите много големи сложни графики само с два или три свързани обекта.
Не забравяйте също, че можете да използвате конфигурация, за да поставите различни обекти в различни хранилища, дори ако всички споделят един контекст по време на изпълнение. Това може да ви позволи да поставите временна информация в един магазин, да го използвате като по-постоянни данни и след това да изтриете магазина, когато приключите с него.
Core Data ви дава повече възможности, отколкото може да изглежда на пръв поглед.
person
TechZen
schedule
09.03.2011
