Abstracting Parse objects?

Question

I want to use Parse (parse.com) in my app. Parse uses PFObject models. I'd like to use my own models throughout my code (so that it doesn't depend on parse). If possible I'd like to design my app so that I can replace parse with another cloud service as seamlessly as possible if I wanted to.

Is this a good idea? What's the best way to abstract the model storage so that there is no (or minimal) traces of Parse code in my app?

Perhaps use the adapter design pattern to map parse objects to my own objects? Should this be an independent class or part of the model logic?

If anyone has tried something like this I'd like to hear your thoughts. Should I just use parse models directly in my code? Or perhaps a singleton factory to generate my models based on parse objects?

Any tips/thoughts/comments ?

Answer 1

I've found relatively clean way to manage this.

Basically I've created a protocol called NPDictionaryRepresenting which classes can conform to in order to specify how they should be converted into a dictionary or initialized from a dictionary.

@protocol NPDictionaryRepresenting <NSObject>
- (NSDictionary *)dictionaryRepresentation;
+ (id)objectWithDictionaryRepresentation:(NSDictionary *)dictionary;
@end 

Each of my models that I need stored in Parse will conform to this and implement their own custom behaviour. This protocol is abstracted through the use of dictionaries so it doesn't depend on Parse in any way.

Then I've implemented a NPNetworkAdapter base class to handle all network storage. I've also implemented an NPParseNetworkAdapter class which inherits from NPNetworkAdapter. This is the only class which knows anything about Parse. Its interface deals with objects that conform to NPDictionaryRepresenting. The parse network adapter is able to create PFObjects by extracting dictionary representations of my objects. Conversely it's able to fetch PFObjects and give me back my own models by instantiating them using dictionaries.

The drawback with this implementation is it doesn't work very well with object relationships (but I'm working on it).

If anyone has any comments on this approach I'd love to hear them.

Answer 2

I realise this is an old question, but I'm busy working on a project that poses this exact same problem so I thought I'd comment. Firstly, I think you did well to identify this and to try and avoid coupling your code too tightly with Parse.

The route I have decided to take is to make use of Protocols (Interfaces) for my model classes with the underlying implementation being the Parse objects - using the Parse subclassing feature; I've combined this with the use of factory classes to decouple object creation and implementation specifics from most of my application code. This may seem like overkill and does require a bit of extra code upfront, however, I believe it will pay dividends with testing and if the time ever comes to change how I access back-end services.

The other alternative for me was to make use of wrapper classes which just wrapped the PFObjects. However, in my case, the wrapper classes would've just been dumb delegation classes without the added benefit Protocols provide for testing, so I stuck with the Protocols approach.