5

After browsing the apple docs, I came across this sample of their MVC pattern:

mvc

Using NSNotificationCenter and without using KVO, would this diagram below represent a correct implementation of the MVC pattern? If not, what’s wrong and how can it be corrected or improved?

mvc example

  1. App starts with the left light set to on, and the right one off. Only one light may be on at a time.
  2. Users presses the right switch, which sends a target action to the view controller.
  3. The view controller receives the message, and send a message to the right light data model.
  4. The right light uses NSNotificationCenter to notify the controller the right light has changed.

  5. The controller receives the message, and performs the following method

    BOOL rightLightOn = [rightLightData on]; if( rightLightOn ) { [rightLightImage setImage:onImage]; [leftLightSwitch setOn:NO]; } else { [rightLightImage setImage:offImage]; }

  6. The switch change causes the UISwitch to call the method “leftSwitchChanged” in the controller.

  7. The controller receives the message, and send a message to the left light data model.
  8. The left light uses NSNotificationCenter to notify the controller the left light has changed.
  9. The controller receives the message, and again performs the same method shown above, but modified for the right light.

In addition, what if the system wasn’t using a switch, and instead was using a UIButton that displayed the text, “Turn On” or “Turn Off.” Would the switch update it’s own text, then call “rightSwitchChanged” or would it call rightSwitchChanged immediately and wait for the view controller to change the text?

Improve this question
0

2 Answers 2

Reset to default
4

Yes it fits the pattern. But...

I'm not a fan of notifications in iOS. In fact in many cases they are used as glorified gotos.

If you call [model setLightOn] why would the model need to send you a notification back that the light is on? It's on!

One other nit-picky comment: setLightOn is a poor name. setLightOn:NO - does this turn the light off or just ignore the message?

Improve this answer
4
  • "...why would the model need to send you a notification back that the light is on?" That's the way the mediator pattern works, is it not? In this basic example, the light would be simple to turn on, but in a more complex example, the controller may have to set up something more involved, such as a POV light, for example. Also, I chose setLightOn: because this is standard convention in Apple libs, but setLightOn and setLightOff could also be used. I do like the concept of notifications, but I also find myself wondering why they are being used in the example by Apple (shown at the top).
    – TigerCoding
    Feb 26, 2012 at 11:09
  • 1
    Notifications can be useful in a one-to-many scenario but in my experience (inheriting some spaghetti OPC*) they can be avoided and the model's state can be queried or set directly to much better effect. When your controller changes the state of some piece of data in your model, the controller then has the responsibility to inform the view. If two or more controllers need to know about that state change I would question the design in 99 out of 100 cases. *OPC: Other People's Code
    – steve_sch
    Feb 26, 2012 at 15:38
  • So it may be better to remove the notification, and have the controller directly pass the data to the view for representation, correct?
    – TigerCoding
    Feb 26, 2012 at 16:00
  • That's what I would recommend. There's a place for notifications but IMO each controller should be responsible for communicating with and maintaining the state of the model rather than listening for notifications that might come from left field. Then the controller deals directly with its view to represent the state.
    – steve_sch
    Feb 26, 2012 at 17:29
1

Does it fulfill your requirements?

MVC, like all such software patterns, is subject to evolution. There is no "right" or "proper" way.

For example, it's possible to bolt on a Javascript library to ASP.NET MVC, and have Model-View-ViewModel, where most of the client action actually takes place in the browser. Some argue that this is a "purer" approach, and there are certain advantages to doing it this way.

Don't be an architecture astronaut, or get locked in to someone's idea of the "right way." Do what works.

Improve this answer
3
  • I appreciate your answer, and I already think that way to some extent, but I was looking more for recommendations as to whether this basic MVC design looks good or not. If you were applying for a job interview, and asked the question above, what would be your comments?
    – TigerCoding
    Feb 24, 2012 at 18:13
  • I would say exactly the same thing. People get bogged down in these wandering generalities when they should instead be weighing the pros and cons of their particular design decisions. Like all good patterns, ASP.NET MVC is a starting place. From there, you decide whether or not it should be modified to better suit your specific requirements.
    – Robert Harvey
    Feb 24, 2012 at 18:15
  • I think an important point is that proper MVC allows for code reuse. You can change your views (for example, moving from a mobile application to a desktop or web application) and your model will be kept the same. Not every application will be required to take advantage of this though.
    – Piovezan
    Jul 30, 2013 at 12:16

Your Answer

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

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