且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

IPad App拉取和推送关系数据

更新时间:2023-01-19 13:53:22

一种流行的方法是将服务器端对象转换为JSON,然后将JSON字符串发送到设备。在设备上,使用一些JSON框架将JSON解码为NSDictionary / NSArray值(我建议 JSONKit ,因为它非常简单和非常快)。

A popular approach is to convert your server-side objects to JSON, and then send the JSON string to the device. On the device, decode JSON into NSDictionary/NSArray values using some JSON framework (I suggest JSONKit since it's very simple and very fast).

一旦你有了解码的JSON,就可以使用(无耻的插件警告)这种技术将您的NS *对象转换为CoreData对象,并将它们保存到手机上。

Once you have your decoded JSON, you can use (shameless plug warning) this technique to turn your NS* objects into CoreData objects, and save them onto your phone.

至于维护关系,您可以使用嵌套表示或平面表示。嵌套实现的示例如下:

As for maintaining relationships, you can either use a nested representation or a flat representation. An example nested implementation would be:

{
    class: "Contact",
    first_name: "John",
    last_name: "Doe",
    contact_type: {
        class: "ContactType",
        type: "some value"
    },
    department: {
        class: "Department",
        name: "Department of Transportation"
    }
}

如果您有一个没有关系周期的简单数据库,这是一种首选方法。

This is a preferred approach if you have a simple database, with no relationship cycles.

或者,您可以使用平面代表:

Alternatively, you can use a flat representation:

{
    class: "Contact",
    id: 1,
    first_name: "John",
    last_name: "Doe",
    contact_type_id: 15,
    department_id: 34
}

{
    class: "ContactType",
    id: 15,
    type: "some value"
}

{
    class: "Department",
    id: 34,
    name: "Department of Transportation"
}

然后你必须在设备上使用contact_type_id和department_id手动解决关系。

Then you would have to resolve the relationships manually using contact_type_id and department_id, on the device.

***测试这两种方法并查看哪一个在你的特定情况下效果更好。就个人而言,我建议使用嵌套方法(如果你的数据库布局允许它),因为它更快,并且在服务器(你可能负担得起)上完成关系解析,而不是在设备上(你可能可以'如果你有一个庞大的数据库,那就买得起。)

It's best to test both of these approaches and see which one works better in your particular case. Personally, I'd recommend the nested approach (if your DB layout allows it), since it's much faster and relationship resolution is done on the server (where you can probably afford it), instead of on the device (where you probably can't afford it if you have a large database).