macOS Proper MVC Controller Design

[rossipoo]

I have a project that I used the MVC pattern for, but it still seems really messy to me. The controller basically duplicates all the functionality of the model, each getter and setter is implemented twice, once in the model, and then again in the controller, which just forwards to the model's own.

I have tried using key paths like [controller valueForKeyPath"model.property"] from the views, which is a bit less code, but is this defeating the isolation of the model by making the view "aware" of the model?

 

[HiRez]

You can store a reference to the model and call into the controller for the model before accessing it. You are cheating, kind of, by directly having views access the model, but at least you're still giving the controller some, uh, control. For example, it could change out data source without necessarily modifying your code. But yeah, it does often get messy that way and you have to make the choice of making a lot of "passthrough" methods or cheating to make it easier.

I haven't seen a lot of Cocoa apps that strictly follow a 3-way MVC separation. Very often the model and controller are the same object. It's more like MC + V. If it's not really critical for you to maintain that separation, I wouldn't worry too much about bending those rules. Remember it's better to have a shipping app than a perfectly technically designed one.

 

[GorillaPaws]

One way to help think about MVC is to picture the app's architecture if you had 2 extra views wired up to it: an AppleScript interface "view", and a terminal command-line interface "view". If you think about how you would structure your app to accommodate those additional views while keeping everything modular you should have a decent sense of of how to layout your classes without them.

 

[Detrius]

Remember it's better to have a shipping app than a perfectly technically designed one.

Of course, this is the whole point of many design patterns--to help you get your app shipping more quickly. The purpose of the MVC pattern is to separate your view from your data. If you later need a different way of viewing the same data, you simply create a new controller to interface between the two--without rewriting view classes or data classes.

Therefore, before you start cheating, consider the consequences. If you have to change the way your data is stored, then everywhere you cheated, you'll have to rewrite your code.

Example: you started by putting all of your data in a hierarchy of Objective-C objects, but you've decided a SQL database would be better. In this change, your existing data classes disappear, and your controller gets rewritten to interact with a database. Your views don't get rewritten.

 

[HiRez]

Of course, this is the whole point of many design patterns--to help you get your app shipping more quickly. The purpose of the MVC pattern is to separate your view from your data. If you later need a different way of viewing the same data, you simply create a new controller to interface between the two--without rewriting view classes or data classes.

Therefore, before you start cheating, consider the consequences. If you have to change the way your data is stored, then everywhere you cheated, you'll have to rewrite your code.

Example: you started by putting all of your data in a hierarchy of Objective-C objects, but you've decided a SQL database would be better. In this change, your existing data classes disappear, and your controller gets rewritten to interact with a database. Your views don't get rewritten.

Right, I agree, but not every app needs that level of separation and abstraction. It tends to take more time to build software with everything perfectly separated into MVC (see the OP's comments about writing passthrough methods...more "plumbing"). I'm not saying don't do it; by all means strive for it, do it if you can, but there is such a thing as over-engineered software.

 

[Detrius]

but not every app needs that level of separation and abstraction.

Agreed, which is why it helps to consider the future possibilities of your own program.

 

[rossipoo]

Thanks for your comments. I think I have a better idea on what to expect from MVC now. It's not so much less work now, as it is potentially less work later.