objective c - How to use Core-Data best in complex Apps -

i mac app dev , have questions how use core-data correctly.

i have multiple tableviews , playing around same data (which want save persistently core-data). know central part of core-data have work - nsmanagedobjectcontext , know how create nsmanagedobjects , save/edit/delete these in persistent store. i'm wondering how organize multiple viewcontrollers,views,tables,.. efficiently and without merge conflicts. i've read approaches that: 1 passing context down delegate through every layer of code. else suggests create singleton-class, let's call databasemanager, holds nsmanagedobjectcontext instance , go , ask there. (i approach, don't know why.) or ask delegate every time [[nsapplication sharedapplication] delegate], have disadvantages?

okay, lot of questions here how. want know recommendations of where should interaction managedobjectscontext. (to in compliance mvc , don't mess code , make more complicated has be..)

• should save stuff core-data in nstableviewdelegate/-datasource classes directly or fire notification else?
• should implement instance methods model-objects (like -(void)saveinstancetodatabase,..) encapsulate core-data-interaction?

ok in advance brave guys read until point , give me kind of response :d appreciate code-examples!

after years of working core data... i've come conclusion it's not good. there serious flaws in it's design can solved abstracting whole thing away.

i recommend implementing own model manage objects, uses core data underneath not ever expose it.

your views , controllers , application delegate , of should not ever touch core data @ all. should talk series of classes create yourself, has been custom tailored particular application.

that object layer can use core data underneath, or might use else fmdb or nscoding or plain old nsdata objects (this fastest option, if need extremely high performance large amounts of data, when combined features nsdatareadingmappedifsafe).

start core data. @ other options if have problems. having own layer on top means can abandon in future. , many developers have chosen move away core data shortly after app ships public. due unsolvable bugs or performance issues.