Do NSURLConnection service objects and XML/JSON parser objects fall within the controller layer or the model layer? Why?

Is it OK to have business logic in the controller? Or should it be in the model layer only?

Can the model layer be represented by NSArray/NSDictionary objects or should it be strictly structured with custom objects to comply with the MVC pattern, given that my app doesn't require persistent storage.

3 Answers 3


All your business rules (and application) should be in the model layer of your application. The controller should just be collecting (from models to views) and sending (from URL requests to models) the data.

Your models can be composed in two layers, the business logic (and application) and your data access layer. Your data access layer execute queries (SQL, NoSQL, Web Service or even text files).

Your models should not be "aware" of the type of storage you are using. This way, you can change and combine different data access mecanism (your users are in a database and the rest of the data comes from a web service for example).

To cleanly integrate your data access layer in your models you should rely on dependency injection


I don't think you should apply a hard rule as where service modules should be applied. Most of the time services are used by the model, but there is quite a bit of variability.

For example, a view that loads a resource from a URL will interact with a network service, or a controller may use a parser service after pulling data from a model and adapting that data to a view.


Controller's job should be to just handle request , validate it and call appropriate model component to do the actual job and once control comes back send the response back to client/view.

So things like parsing or any actvity/processing which is specific to service should be done at Model layer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.