Is CoreData typically used as the Model or is it an implementation detail of the Infrastructure?

Question

I would like to use a Sqlite datbase in an iphone application. The example in the book I am reading has the controllers directly calling into CoreData objects.

Coming from MVC/MVP in .NET to me this is akin to opening a SQL Connection in a button event handler. I would typically have a repository that handled the details of retrieving/persisting the model.

1) Is it the norm to use CoreData functionality directly in a Controller?

2) Is extracting my domain model into separate classes that get translated back and forth to the persistence layer not a good idea on the iPhone (in regards to performance, memory, expected project organization, etc)?

3) Will creating a repository layer work well on an iPhone?

Going with the SmallTalk background Objective-C and the MVC approach of iPhone applications I was expecting to leverage Domain Models, Repositories, IoC, etc.

Is that just not realistic? Are the author and I just on different pages? Thanks for any input.

Answer 1

iPhone SDK does follow the MVC pattern, but also many others (delegate). So it may not be as strict as other languages you mentioned. To answer your questions:

1. You will inevitably have some kind of access to your Models from your Controller. The CRUD actions will go here. So long as the actually performance of these actions is handled within the Model than you are following the MVC pattern. This is provided by the CoreData Framework. So in the end, it is your DAO, ActiveRecords, etc.

2. You can generate the Model classes (Model.m/h) if you wish to add extra functionality. However, CoreData typically builds them for you on the fly.

3. I don't quite understand this without a .NET background, but I think my answer to your first question may have answered it indirectly.

I can't speak to the book you are reading, but it may be best for you to see some additional references. Check out the Introduction to Core Data in the ADC's Reference Docs as well as one of the sample projects - CoreDataBooks.

Answer 2

Yes, Core Data is typically used as the model. If I understand what you are saying correctly, you expect a layer between the actual data store and the controller. Core Data is that layer -- it (sometimes) is implemented in sqlite, so that you never actually use sqlite directly. This is I think the source of your confusion -- you're not supposed to use both in the same project for the same data.