iOS MVC architecture - separate view other than the view of view controller

Overview

• I am doing an iOS project using the MVC architecture. I am just confused, I am looking for a good design.
• The view I am planning to use will have some buttons on it and some labels and text fields. My view wouldn't need any custom implementation of drawRect.
• All my logic as to what needs to be done when a button is pressed or an event occurs is in my view controller

**I have a couple of doubts: **

1. for the above scenario, is it still better (good practice) to create a separate view (a view other than view controller's view)? If so why?

2. Other than drawing and displaying the view (in my project, I don't have much of it) what else should a view's implementation code contain?

3. I would like to disable a set of buttons when the user touches on a text field and the keyboard comes up.

   a) So should I place this logic of disabling some buttons in the separate view's implementation (view created in question 1) ?

   b) From my parent view (view created in question 1), can I create outlets for the buttons (which are subviews) to disable some of the buttons? I am not able to do this. Or should I use the method subviews and loop through the button that I am looking for?

My understanding

1. Model contains the data

2. View is responsible for displaying and shouldn't contain business logic.

3. View controller is the only one to interact between the model and the view and contains the business logic

1. There's no need to create a separate view -- the view controller's view (usually just a plain UIView) can certainly contain your buttons and text fields. If you did want to put some of those in a separate container (perhaps so that you could move them as a group), you could use a plain old UIView for that.

2. Views are responders, so UIView subclasses can override the touch handling methods if you want to do any special touch handling.

3. a) It's common to put the code that manages views (such as disabling buttons) in the view controller. b) Again, you'd normally put the outlets for your buttons in the view controller.

When people talk about "business logic" they usually mean the logic that's required to maintain and operate on the data that the application deals with. That sort of thing is often best placed in the model. On the other hand, code that manages views, such as enabling or disabling buttons or moving data from the model into views (or vice versa) belongs in the view controller.