I'm retro-fitting core data around an existing project and I would like to know which is better for efficiency reasons.
a) Create a model object with an attribute that is of the type of my current model class, then make the object transformable to NSData.
or
b) Subclass NSManagedObject, give it all the ivars of my model object and on fetch / insert do a translating to a model object (fetch) or an NSManagedObject (insert).
Thanks,
Tim
It seems like you don't really understand the purpose of core data. Core data is a mature object graph that can be attached to a persistent store, like SQLite. Whenever you fetch something out of core data, it is already a model object. You use the NSManagedObject as your models, there's no real reason to pull the data out of the NSManagedObject and into a different object.
Before you go further, I recommend that you take a hard look at http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/coredata/cdprogrammingguide.html
Related
When I have worked with Java applications involving a database and ORM (object relationship manager) the architecture was usually separated so when working with database entities in the database layer you worked directly with the entities. But if you needed to access the entities in the GUI you would create a data transfer object (DTO) of the entity and then use it in the GUI layer.
What is the preferred approach in iOS applications?
One example would be that I do a fetch from Core Data to retrieve some objects in a ViewController and then display the results in a TableView in the ViewController. Is it necessary to convert the NSManagedObjects to DTOs before showing the results?
What is the preferred approach in iOS applications?
Is it necessary to convert the NSManagedObjects to DTOs before showing the results?
No, it is not neccessary. The managed object is already a (generic) object wrapping the database entity. You can access the managed object's properties (ie the entitys attributes) using -valueForKey: calls.
But the preferred approach is to subclass NSManagedObject to fit your entities. In Xcode there is an option to generate subclasses automatically (editor-> generate NSManagedObject subclass). That way you get your own subclass object for your entities and can access their properties using dot notation.
On fetching objects, just let the result be of type of that subclass.
If you want to add custom methods to your entity objects, you should create a category on your managed object subclass. This is because if you change your db scheme and have to let xcode recreate your subclasses, it completely overwrites the and your custom methods would be lost.
I am working on an iPad application, that requires me to store data locally if the user doesn't have internet access and later on sync with the back-end database.
For local storage, I am planning to use Core Data with SQLite.
I am using Core Data for the first time and it seems, it retrieves entity and store entity in the form of a dictionary.
So should I be creating Model classes at all ?
What is a good design for such application.
I have a DataEngine class whose responsibility is to store entity on a server or local DB based on connectivity.
Now I am little confused If I need to create a Model class and ask individual model classes to save themselves using NSMangaedObjectContext with a dictionary representation Or just directly save data instead of creating a model object and asking it to do it ?
Should I be using a Moel class for each entity and that will server as interface between JSON representation that coms/goes from/to server.
and the representation I get from managedObjectContext.
Or shall I compeletely rely on the entity and relation ships that Core Data creates ?
I'll do this backwards: first some things for you to check and then some ideas.
Check my own question.
I'd say that on your custom categories you can do the interface between the JSON representation and your classes.
You should also check RestKit which can do already much of what you need.
You're talking about two separate problems as far as I can understand:
Syncing local data to the server based on connectivity;
Using model classes.
Problem 1
I think you should have a class with the common code and each of your model classes should have its own mapping (to map between model and JSON) and saving methods.
Another class, that may be your DataEngine class, takes care of saving the right objects at the right time.
Take a look at RestKit as it helps with the mapping and the saving. I'm not sure about the syncing though.
Problem 2
I think you should have model classes. It helps a lot to work with objects and you have then a place to save methods for finding different kinds of data.
For this my question might be useful for you because you can create a CoreData model with generated class files and update it whenever you want while keeping your custom code.
I need to persist up to a maximum of about 100 complex objects (call them Object A). I say complex because each object is composed of other nested heirarchical objects.
I decided against storing them in core data because of their complex object graphs, so I was thinking of using archiving for persisting these objects.
However, I need to form relationships between these objects and other managed objects in core data (call them Object B). The cardinality is one object A (archived) to many object Bs (core data).
My question is, what would be the best way of doing this? I thought of using UUIDs for each archived object A and storing references to those UUIDs as string attributes in core data for Object B.
But I understand there may be performance and storage penalties associated with doing this. Is there another type of object ID for Object A perhaps that I may use?
It seems for all the effort you are going to put into mapping between CoreData and your archived object, it would just be easier to put it all through CoreData. If you have "complex" properties in this object that makes using CoreData undesirable, don't forget that CoreData has a transformable property.
This might be what you need.
I have RestKit setup nicely with a Core Data managed object backing but I have some fields which are not present on the server, only in the local model class.
How can I set these fields before the object is persisted. Is there something like a 'willSave' delegate method I can implement?
Thanks
I don't quite understand what you want to accomplish, but you can override willSave in NSManagedObject. The docs give a good explanation of what it does.
If you want to modify the incoming data before you save it, you should consider willMapData
I am building an app where my primary model objects can either be fetched from a Core Data store or from an external source (public API via internet - > JSON - > object). I'm new to Core Data so my question is can I just take my model object as it stands now and make its superclass NSManagedObject? I'd guess that I'd need to make sure my model's properties match the names and types of the data model entities for this to happen. I don't want to have to use two different model objects in the app - one when I fetch from the core data store and one when I fetch from the internet API.
Is there anything else I'd need to do to make my already built model objects compatible for use with core data?
Any guidance or advice would be much appreciated.
Regards,
Craig
You can add some business logic to your object (subclass of NSManagedObject) to enable to creation of such an object from data (ie an NSDictionary of values to be used). The crux will be deciding whether you want those objects managed/saved to your local datastore or not.
I highly recommend becoming familiar with NSManagedObjectContext: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObjectContext_Class/NSManagedObjectContext.html
What I have done in a couple of products is just deal with core data objects, and initialize them from data that I pull from the web service. That way you only have apples. Another option would be to make a protocol that defines the behavior of the analogous classes. You would be tempted to make one the subclass of the other, but that could get complicated, depending on your persistence requirements.