Simple MVC setup / design?

Question

I just want to make sure that I am heading in the right direction with how a simple MVC application is constructed.

// MODEL
@interface Reactor: NSObject {
    NSNumber *temperature;
    NSString *lastInspection;
    NSNumber *activeRods;   
}

.

// CONTROLLER
@interface viewController: UIViewController {
    UITextField *tempTextField;
    UITextField *inspectTextField;
    UITextField *activeTextField;
    Reactor *reactor;
}
@property ...
...
-(IBAction)ButtonPressed;
@end

.

Am I right in declaring the reactor (dataModel) in the controller? The way I see it the controller sits between the [VIEW] and the [MODEL] so its going to need links to both.

The [VIEW] is linked via "IBActions" to methods implemented within the [CONTROLLER] which in turn sends messages to methods in the [MODEL]. The [MODEL] does any processing/data manipulation needed, sending any required results back to the [CONTROLLER] which in turn may be used to update the [VIEW].

Does this sound sensible, in simple terms?

gary

Answer 1

You can risk this for a very small, simple model but you really shouldn't develop it as a habit because this method will breakdown as your projects get larger.

What happens when you have an app two or more views both taking data in and out of the model? What happens when you have an app with multiple views and gets data from a URL? What happens if you want to use the data model in an html or even a command line interface. What happens when you want to use the data model in another app altogether?

If your going to be writing serious code that will have thousands of users, multiple versions and possibly spinoffs, you need to develop good habits early.

The best method for a data model is to create a singleton to hold it. I would suggest creating a generic singleton class and then making your model for any particular project a subclass of that class. That way you have a neat contained model that can be accessed from anywhere in your app.

The second best method is to park the data model object in the app delegate. However, that to can become unwieldily as the project scales.

It certainly doesn't help that every piece of instructional/tutorial information I have seen pretty much ignores the data model in favor of teaching you how to do the eye candy for the interface. The data models are just simple arrays or some such tacked onto the side of a controller.

Trust me, you don't want the nightmare of growing and growing your app only to discover that its data model logic and data are scattered over a a dozen view controllers. Grit your teeth and do it correctly from the get-go and you'll never have to sweat it.

Edit01:

Singleton, I will have to do some research, can you explain a little how you would access that from the [CONTROLLER]? Just curious if the [MODEL] goes in the AppDelegate again how would you access it from the [CONTROLLER]?

You park a data model in the app delegate by (1) making the data model object a property of the app delegate and (2) using the global reference form for the app delegate:

MyDataModelClass *theModel=[[UIApplication sharedApplication] delegate] dataModelProperty];

Creating a singleton is a little more involved. You use it like you use the NSFileManger. You would reference it the same way.

NSFileManger *fm=[NSFileManager sharedInstance];

This ensures that only one file manager is active in an app. You would call the data model the same way from a controller:

MyDataModelClass *theModel=[MyDataModelClass sharedInstance];

If you carefully design the data model object such that it has complete control over what information is written to it, you can safely use it anywhere without having to worry that your data will be trashed by a one careless line of code.

Answer 2

You're right the model should store all your bussiness related object and they can be MODIFIED through the controller, the view make calls on the controller depending on the user actions.