Question

It’s a fairly common scenario for an application to pull data from a server (usually a JSON string). This data is then parsed and converted into native classes like NSString, NSArray, NSDictionary, etc.

Most of the time, however, we want to use custom models to represent this remote data.

For example if we’re pulling a JSON array of blog posts we’d want to map those into BlogPost model objects for example:

// BlogPost.h
@interface BlogPost: NSObject
@property NSString *title;
@property NSString *body;
@property NSDate *dateCreated;
@property NSArray *comments;
@end

What’s your approach for decoupling the “JSON” model from the native model?

I often find myself writing a custom initializer in the model itself which takes a dictionary (which typically comes from the JSON feed).

For example:

// BlogPost.h
+ (BlogPost *)blogPostWithJSON:(NSDictionary *)jsonDictionary;

Then I have to keep track of the keys used on the server and map those to my properties.

I always feel a little uneasy doing this because the model in the application shouldn’t really have to know what keys are used on the server.

Should I instead move this JSON-to-Object mapping in another class? Perhaps a Factory? Or should my network manager be creating and returning ready made objects to me directly?

Perhaps something like:

// NetworkManager.h
- (void)getBlogPostWithCompletion:(void (^)(BlogPost *blogPost))completionBlock;

(Of course I’m omitting lots of details here like which blog post to get but it’s just to demonstrate an approach).

Any other approaches? How do you decouple your server data from your local models?

Answer 1

I have faced this problem a couple of times and got pretty much the same questions as you. In the end what I find works for me is:

• Create an OO representation of the original model. In your case this would mean decoding the JSON array into whatever it uses as an underlying model (a dictionary?). Depending on how is modeled the service that you are using, you may end up with some “record classes” (i.e. classes without behavior). I generally prefer to have these type of classes instead of arrays or dictionaries, since as your software evolves this allows to add behavior to them if you need. If, on the other hand, you use arrays or dictionaries you can’t do that.
• Once you have a low-level OO model, create an OO domain model. In this new model you design things as your domain requires and not tied to the service provider’s model. Many times you will find a 1 to 1 mapping between your domain classes and the provider’s one, but that is not mandatory. The point here is that you should abstract your domain and design it as you feel is right.

The mapping between this two models can be done in different ways, according to its complexity. I generally like to pick one of these three approaches and stick to it in order to have an homogeneous approach in the project:

1. Write a class method (class)HighLevelObject>>from(aLowLevelObject) in your domain model. This takes a low level object and configures itself. You do this for all your high-level objects that have a low-level counterpart.
2. The opposite to the previous one: write an instance method LowLevelObject>>createHighLevelObject() in the low level object that creates an instance of your domain model. Here you a re shifting the responsibility of creating a new object to the lower layer.
3. Create a factory or builder (depending on the complexities of your models) that takes care of the whole creation process.

If you have simple models with many 1 to 1 mappings between them I would go for options 1 or 2. Which one to choose depends pretty much on your tastes; the option 1) has the advantage that the object knows how to construct itself but places the transformation process burden in the domain model. The second approach leaves a “cleaner” domain model, but forces the lower layer to know the details of the upper one and may force you to break encapsulation. I don’t think that there is a silver bullet here; IMHO you should choose the approach that best fits your needs and programming tastes.

HTH