views:

35

answers:

1

So I've been trying to design a clean way of grabbing data for my models in iPhone land. All the data for my application is coming from JSON API's.

So right now when a VC needs some models, it does the JSON call itself (asynch) and when it receives the data, it builds the models. It works, but I'm trying to think of a cleaner method whereby the DAO's retrieve the information for me and return the models, all in an async manner.

My initial thought is build a protocol for my DAOs, such that the VC would instantiate a DAO and make itself the delegate. When you requested data [DAOinstance getAllUsers] the DAO would do all the network request stuff, and then when it had the data, it would call a method on its delegate (the VC) to pass the data.

So I think that's a cool solution, but realized that if I needed to use the same DAO for different purposes in the same VC, my delegate method would have to branch logic depending on which DAO instance initiated the request.

So my second thought was to be able to pass 'handler' selectors to the DAO object a la typical javascript patterns. So instead of an official protocol, I would say something like [DAOinstance getAllUsersWithSelector:"TheHandlerFunctionOnMyVC:"] Then when the DAO completed its network activities, it would call the passed selector on the VC, and pass the data back.

So am I headed in the wrong direction entirely here? Seems like maybe an ok way to go.

Any pointers or articles on designing this kind of data layer would be sweet.

Thanks! Bob

+1  A: 

It's pretty common to pass the a target (your VC here) and a selector (the handler method) when you need a call back and don't want to branch on the handler method caller. This is called the target-selector pattern.

Apart from that you might want to check out the RestfulCoreData and CoreResource frameworks on possible designs of this.

Also the famous ObjectiveResource framework might provide a good insight.

E-ploko