Separating back-end from view controller logic

In a project I'm working on I'm using Parse.com as a back-end. I had developed several screens with various loading and saving functionality and I started thinking about how difficult it would be to replace Parse.com with another back-end solution (if the need arose). This lead me to doing a pretty hefty refactor of the existing codebase.

I'm not sure if my approach is something to emulate as this is my first iOS app, but in case it has some merit I thought I'd share it here.

My goal was trying to limit the scope of my changes on the iOS app side if I needed to move to a vanilla web server back-end or another BaaS like StackMob etc..

So I decided that all Parse.com methods should go into only one class which I called Backend. The idea would be that all the changes required would be limited to this class. So there were a few things I needed to do:

1) I had to make sure that my data model objects had a clear interface and that nothing came out of the Backend method calls as a Parse-related type, only as app-specific types that I had created and that would not change from implementation to implementation.

2) All the actual method calls that talk to Parse occur only in the Backend class. So my User class will have an instance method called "save" and that would simply call [Backend updateUser:self] or similar. All the methods were class methods as I didn't want to bother creating an instance of the Backend class.

3) In my Backend class I would have methods to convert into the Parse objects and back to my application-specific types.

4) I did make one concession to Parse that I can probably work around once I think about it more, but I do store the Parse object as a property in my application object just for the sake of having its key. I don't do anything with it in the application outside of the Backend class except to declare it as a property. The property is simply called backend and I could possibly change it to just store the Parse objectId instead - but it's a small concession which won't hurt me in a transition. To the application itself, it does not matter whether that property has a value or not.

The other good thing about having the Backend class is that it's immediately apparent to me exactly what needs to be re-implemented during transition as it can serve as it's own interface spec.

Of course, actually replacing the functionality in the back-end can be more complicated, but that's exactly why I wanted to simplify the changes on the app side.

I don't know if this resonates with anyone and I guess it could be considered a bit unnecessary, but I really hate feeling tied to a specific service. The amount of work it took to do all this at these early stages was enough that I could see it becoming impractical to try to refactor it after the app grew past a certain stage.

Anyway - for what it's worth.