iPhone 용 JSON 저장소 만들기

Question

우리는 원격 웹 서비스의 데이터를 JSON으로 가져와 파서를 사용하여 코어 데이터 모델로 변환하는 많은 응용 프로그램을 보유하고 있습니다.

우리 애플 리케이션 중 하나에 대해 나는 뭔가 다른 것을해야한다고 생각하고있다.

이 응용 프로그램은 휘발성 매우 긴에 대한 로컬로 캐시 때문에 하지 읽기 전용 데이터을 가지고 있습니다. JSON은이고 중첩 된 객체 톤이 인 입니다. 문서는 일반적으로 20 개 이상의 최상위 항목을 포함하지만 최대 100K 일 수 있습니다.

100 개의 엔티티가있는 코어 데이터 모델을 만든 다음 매퍼를 사용하여 JSON을 가져 오려고한다고 생각하지 않습니다. 그것은 그런 노래와 춤처럼 보인다. JSON을 어딘가에 쉽게 유지하고 쿼리 할 수있는 기능이 필요하다고 생각합니다. MongoDB는 아이폰에서 실행된다면 괜찮을 것이다.

iPhone에 쿼리를 지원하는 JSON 문서 저장소가 있습니까?

또는 일부 JSON 파서를 사용하여 데이터를 영구 NSDictionary로 변환하고 조건자를 사용하여 쿼리 할 수 ​​있습니까?

또는 SQLite를 JSON 구조에 수동으로 생성 한 인덱스가있는 BLOB 저장소로 사용 하시겠습니까?

또는 징징 대는 것을 멈추고 코어 데이터를 사용해야합니까? :)

감사합니다.

Answer 1

사용할 지속성을 결정할 때, 핵심 데이터가 객체 그래프 관리 시스템의 제일 중요하다는 것을 기억하는 것이 중요합니다. 진정한 기능은 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은 매우 휘발성이 높은 데이터도 효율적으로 처리 할 수 ​​있습니다. UI가 똑같이 단순하다면 UI를 iOS/MacOS 앱의 객체 지향 디자인에 통합하는 데 약간의 오버 헤드가 발생합니다.

(3) 데이터가 더욱 복잡 해짐에 따라 핵심 데이터가 신속하게 우수 해집니다. "관리되는 객체"의 "관리되는"부분은 관계 및 동작의 복잡성을 관리합니다. 컬렉션 또는 SQL을 사용하면 복잡성을 수동으로 관리 할 수 ​​있으며 자신을 빠르게 찾을 수 있습니다. 실제로 SQL을 사용하여 복잡한 데이터를 관리하려는 사람들이 자신의 미니어처 코어 데이터 스택을 작성하는 것을 보았습니다. 말할 필요도없이, 복잡성과 변동성을 결합 할 때 Core Data는 삽입 및 삭제의 부작용을 자동으로 처리하기 때문에 더 좋습니다.

(인터페이스의 복잡성도 중요하지만 SQL은 크고 정적 인 단일 테이블을 처리 할 수 ​​있지만 즉시 변경할 수있는 테이블의 계층 구조를 추가하면 SQL이 악몽이됩니다.) Core Data, NSFetchedResultsController 및 UITableViewController/대의원은 사소한 일로 생각합니다.)

(4) 복잡성이 높고 크기가 클수록 핵심 데이터가 분명히 탁월한 선택입니다. 핵심 데이터는 고도로 최적화되어 있으므로 그래프 크기를 늘리면 SQL만큼 작업량이 줄어들지 않습니다. 또한 지능적인 캐싱을 얻을 수 있습니다.

또한 "코어 데이터가 철저히는 있지만 코어 데이터는 이해하지 못했습니다."라는 말은 "핵심 데이터의 오버 헤드가 높습니다"라고 혼동하지 마십시오. 정말로 그렇지 않습니다. 핵심 데이터가 지속성을 유지하면서 데이터를 얻는 가장 저렴한 방법이 아닌 경우에도 나머지 API와의 통합은 일반적으로 개발 및 신뢰성의 속도를 고려할 때 우수한 결과를 생성합니다.

이 특별한 경우에는 설명 (2) 또는 (4)에 해당하는지 여부를 알 수 없습니다. 그것은 데이터의 내부 복잡성과 UI의 복잡성에 달려 있습니다. 당신 말 :

나는 개체의 100 년대와 코어 데이터 모델을 만들려는 생각하지 않으며, 는 다음에 JSON 를 가져올 매퍼를 사용합니다.

실제 추상 엔티티 또는 여기에 관리되는 개체를 의미합니까? 엔티티는 인스턴스가 될 클래스가 관리 객체에 있음을 기억하십시오. 예전의 경우, 그렇다면 핵심 데이터는 많은 일을 할 것이며, 후자의 경우라면 그렇지 않을 것입니다. 두 개 또는 세 개의 관련 엔티티만으로 매우 큰 복잡한 그래프를 작성할 수 있습니다.

런타임에 단일 컨텍스트를 모두 공유하는 경우에도 다른 엔터티를 다른 저장소에 넣기 위해 구성을 사용할 수 있습니다. 이렇게하면 임시 정보를 하나의 저장소에 넣고 더 많은 영구 데이터처럼 사용하고 작업을 완료 할 때 저장소를 삭제할 수 있습니다.

핵심 데이터는 언뜻보기에 더 많은 옵션을 제공합니다.

Answer 2

JSON Framework은 하나입니다. JSON을 기본 NSDictionary 및 NSArray 객체로 변환합니다. 나는 그런 큰 문서에서 그 성능에 대해 아무것도 모릅니다. 그러나 많은 사람들이 그것을 사용하고 좋아합니다. iOS 전용 JSON 라이브러리는 아니지만 널리 사용되는 라이브러리입니다.

Answer 3

나는 SBJson을 사용하여 JSON을 NSDictionaries로 파싱 한 다음 [dict writeToFile:saveFilePath atomically:YES]을 사용하여 .plist 파일로 저장합니다. 적재도 간단합니다. NSMutableDictionary *dict = [NSDictionary dictionaryWithContentsOfFile:saveFilePath]. 빠르고, 효율적이며 쉽습니다. 데이터베이스가 필요 없습니다.