• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Fwd: MVC Design Question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: MVC Design Question


  • Subject: Fwd: MVC Design Question
  • From: Nelson Santos <email@hidden>
  • Date: Sat, 24 Mar 2007 11:52:34 -0400

Hi all,

This tread that I've started in the Objective-C group is starting to contain Cocoa-related questions, so I am posting it here as well. Any advice is appreciated! Thanks.

Nelson


Begin forwarded message:

From: Nelson Santos <email@hidden>
Date: March 24, 2007 11:41:15 AM EDT (CA)
To: Sven Mertens <email@hidden>
Cc: email@hidden
Subject: Re: MVC Design Question

Hi Sven (and everyone else),

Thanks for the info. What you say makes sense. I'll have a look at that link as well.

You know, yesterday I thought pretty heavily on the subject (maybe I over-thought some of it) but I came up with some additional questions. All of them apply to the type (3) design below (which mean I should be on the right track, I hope!) Let me know what you think:

I have a model object that contains references to sub-objects. Like this:

@interface MyMainModel : NSObject
{
	MySubObject *subModel1;
	MySubObject *subModel2;
	MySubObject *subModel3;
}
@end

I design a window with 3 groups of controls where each group is designed to manipulate one of the subModels in my mainModel. So, I figure the best way to tie these together is to have one controller for each control group/subModel combination. But sometimes, one controller might need to access one of the other subModels or one of the other controllers in the model, so I figure a main controller is required to tie all the controllers together (and also to allow access to mainModel level methods).

I could decide to have just a single controller, but I think for better code organization, 4 controllers is better. Do you agree?

Also, I have a question about the controls that I've laid out in my window. Let's say that one of the control groups is a bunch of NSButtons and an NSTextField (i.e. a keypad with an enter button and a numerical display, for a security key lock style interface). I'd like for this key lock set of buttons to be a single object that I can easily import into other projects, should I ever need it. I don't want this single object to be a window because I may want to place the key lock controls onto an existing window containing other controls. How should I do it? Should I make the group a subview of NSBox? Or maybe a subview of a custom view? That way, I can copy and paste the single object into windows of other projects. And I would expose a single set methods that pertain to the group of controls (i.e. activateKeylock, setKeylockButtonColors, changeKeylockButtonLayout, etc.)

What do you think?

Many, many thanks!
Nelson


On 24-Mar-07, at 2:28 AM, Sven Mertens wrote:


Am 23.03.2007 um 17:33 schrieb Nelson Santos:
(1) The controller passes a reference to the model object, thus giving the model object all the info it needs to do the drawing.
(2) The view object has an attribute that is a reference to the model object, and the controller sets that reference before calling the views draw routine.
(3) The controller reads and parses all the data in the model and sends more generalized data to the view. This way the view need not know anything about how the model works.



If you want to do true MVC, then (3) is the only option that matches the design pattern. Typically the controller and the view are connected only by their IBOutlets and IBActions while the controller owns the model instance. The controller translates the requests from the view to operations on the model, if needed and sends changes in the model back to the apropriate view elements. Note that the controller may control more than one model and do some caching and data polishing on its own.
The idea is really that if your UI is significantly changed (eg. the user gets a completely different view with different options, ...) the model would not have to be changed at all. Likewise if your model choses to trade its array-like propertys for a SQL like query mechanism, the view should not be affected.


I think most of the common XCode-Examples will illustrate this scheme very well. Also you may want to look at http://en.wikipedia.org/wiki/ Model-view-controller (Why is this wiki-page lacking info about XCode, but mentions "Windows Forms" ???)

Sven



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com


This email sent to email@hidden

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Prev by Date: Re: NSString initWithUTF8String - crazy retainCount with empty string
  • Next by Date: Re: NSString initWithUTF8String - crazy retainCount with empty string
  • Previous by thread: Re: NSString initWithUTF8String - crazy retainCount with empty string
  • Next by thread: How to create a Music Score view?
  • Index(es):
    • Date
    • Thread