If you have following questions in your mind
- What is MVC (Model, View, Controller)?
- What is role of Model, View and Controller?
- What piece of code I should place in model, what in controller and what in view?
- DOB that I am getting from server is not according to format that I want to display in view. Where should I place function (method) to format the date controller or view or in model?
- Is cocoa version of MVC different from traditional MVC?
- Does NSNotification in cocoa break the MVC architecture?
Then I am writing this post to help you out to understand the MVC and I will try to answer all above questions in my post.
What is Design Pattern?
A general reusable solution to recurring problem is called design pattern. There are many design patterns for example Factory pattern, Proxy pattern, Façade pattern and also MVC.
MVC Design Pattern?
First of all I will start with basics of each component of MVC (Model, View, Controller) one by one and then I will jump to Objective-C code example, through which I will show how to implement MVC in iOS application.
MVC design pattern makes your code more reusable and extendable. If you want to make change in your code on new requirement, you can change it easily.
Brief overview of MVC
You click on a button on the view in iPhone or iPad (View) to display person information; it is delegated to controller against that button action which gets called when button is pressed (Controller). Controller then calls model to return person info object, so that controller can give this data to view to display it. Now this call to fetch data, fill object and returning that filled object or any value is part of model object (Model).
Model, view, and controller are three different roles that objects can play in an application.
View should be only responsible for displaying data. What can be part of view? For example, if you make a view without nib then your label, buttons, textfields can be part of it. I will show example through code, which will clear the concept. View should not store data but it can cache some data for performance optimization reasons.
Objects in the ‘view’ role make up the application’s interface to the outside world. The user interacts with view objects. View objects know how to display information and collect user input, but they don’t make any decisions about what to do with the data.
We normally create view components alloc/init them, set their frames and add them as subviews in view.
You press a button from view; against that touch there is function that gets called. That function is part of controller. This function can call model to respond back to this call. Controller can communicate to both model and view because it has references to both of them.
Sometimes view can ask for information which view wants to display or sometimes view gives command to store new value in model for example when user enters new values and we press update button. These calls are delegated to controller and controller sends them to model. Model responds back to controller and controller then give data to view to update it.
Controller sits between model and view. If an app needs to display some data, the controller retrieves the data from the model object(s) and gives it to view objects to display. When the user causes some action to happen (say, they press a button), the controller decides how to respond.
You can apply formatter and any kinds of checks here. For example, you are fetching date and it is not according to format that you want. Then you change format in controller before sending to view.
Model objects are those store data and, often logic (operations/ functions) that relates the different pieces of data to each other. For example, if I am fetching data from core data table from employee table then I will create a model object employee with all properties that can. Any data that is stored persistently in application is normally part of Model. In ideal MVC, there is not any kind of contact between model and view.
Is cocoa version of MVC different from traditional MVC? Yes. It is bit different. Because in traditional MVC model, model can communicate with views or view can communicate with model but in COCOA MVC this does not happen. Model and View interacts with each other through controller.
Now if we look at traditional MVC
Final OutPut :
Note: Above are the basic concepts that you should refresh before looking into source code. I will soon upload video which will explain the code.