1

Possible Duplicate:
Understanding Model-View-Controller

I have a general programming question about how to divide up my code, usually (and I'm trying to get away from this) I just write it all in the viewController, lots and lots of code in the view controller. But now i've reviewed some information on the MVC but I have some questions.

My Question

Mainly, if I a view controller (holding a model and a view), and in the model I run a method figures out a number display for the view, so just a simple int which the view would take and display on the screen. In order for my model to tell my view to do this should I go straight from model ----> view. Or should I return the data back to the controller and then send it to the view?

Lastly, if I need to send the data back to the controller, how might I do so, because I thought that the model should'nt know about the controller, only vice-versa.

Sorry for the lengthy question. Thanks for all your help.

Community
  • 1
  • 1
James Dunay
  • 2,714
  • 8
  • 41
  • 66
  • As per as i know for my understanding Model - *Your database* View - *your layout which you create using nib or pro grammatically * Controller - * your UIViewController * – Praveen-K Sep 21 '11 at 14:46
  • Since you tagged your question iOS, I think it is a very good point to look at the question @bzlm refers to. Apple's MVC differs quite a bit from what is normally meant. – Jakob W Sep 21 '11 at 14:56

2 Answers2

0

There's a lot of info about this in the net. From Wikipedia:

Though MVC comes in different flavors, control flow is generally as follows:

  1. The user interacts with the user interface in some way (for example, by pressing a mouse button).

  2. The controller notifies the model of the user action, possibly resulting in a change in the model's state. (For example, the controller updates the user's shopping cart.)

  3. A view queries the model in order to generate an appropriate user interface (for example the view lists the shopping cart's contents). The view gets its own data from the model. In some implementations, the controller may issue a general instruction to the view to render itself. In others, the view is automatically notified by the model of changes in state (Observer) that require a screen update.

  4. The user interface waits for further user interactions, which restarts the control flow cycle.

The goal of MVC is, by decoupling models and views, to reduce the complexity in architectural design and to increase flexibility and maintainability of code. MVC has also been used to simplify the design of Autonomic and Self-Managed systems

Community
  • 1
  • 1
Youssef
  • 3,582
  • 1
  • 21
  • 28
0

As long as you don't use bindings, you can simply have model-classes for your db-operations, views for your interfaceobjects and a controller, that retrieves data from the earlier and puts it in the latter and you're fairly structured. As for the way back: everything you app does, is triggered by one kind of event or another. According to those, you have to fetch the appropriate values from your interface (->outlets). For everything else, you'll actually have to do some further studying controllers and bindings.

Marcus Toepper
  • 2,403
  • 4
  • 27
  • 42