use custom core data persistent store for getting data via webservices?

Question

Is this a good idea? When is it a good idea, and when is it bad?

Just heard about this in one of the WWDC videos, and I don't quite understand why would one want to do it this way. Seems complicated and I cannot see the benefit.

Answer 1

The way I see it, it would be to totally abstract the data access layer. You'd then be able to access the web service using Core Data fetch request API. You'd also be able to implement caching in the persistent store without affecting the application logic.

Also changing the web service request/response format could potentially only affect the persistent store layer.

I see it can be a benefit for large requests. Since networking is quite expensive in battery life, application should use as less bandwidth as possible so developing a single request sending more information but using Core Data to access only subsets at a time is a good design in my opinion.

Finally, I think Core Data API blends well with major ORM web framework like rails or django for example.

Answer 2

It is complicated and it is meant to show what you can do with Core Data. I personally like to keep server communication separate from the local cache and then update the server based on changes to the local cache. This means that I use code that listens for save events from Core Data and then updates the server.