MVC pattern: where does the formatting / processing work belong? (Objective-C)

Question

As my Cocoa skills gradually improve, I try not to abuse MVC, as I did before, when I discovered that I was in a hole built according to my previous assumptions. I have no one here to bounce off of this, so hoping one of you can help ...

I have a custom Model class that has numerous and varied properties (NSString, NSDate, NSNumber, etc.). I need to serialize properties to pass. Sometimes, when this data is processed for serialization, questions may arise that the user will have to answer (UIAlertView, etc.).

Don't get caught up in too many features, where does this code belong?

• The Model says part of me because it is about saving data - in some way.
• Part of me says View because it is a different interpretation of the master data (no pun intended) contained in the model. And the user will sometimes have to interact with dialog boxes when processing data.
• Part of me is the Controller , as it controls the transformation of data between the model and the view.

Is this a combination of all three? If so, how will the relationship between the classes be processed during data processing? NSNotifications? Direct method calls?

Answer 1

It may be something that you would like to use the Visitor template for - http://en.wikipedia.org/wiki/Visitor_pattern - because in the end you will want to use different types of serialization for different things, and you can have different classes of visitors, and not many special cases in the model code.

Here's a discussion of the visitor pattern in objective-c / cocoa: http://www.cocoadev.com/index.pl?VisitorPattern

Here (old !!!) is an article from Dr. Dobbs about the visitor pattern in objective-c: http://www.drdobbs.com/184410252

The reason that the problem you're working on doesn't fit very well with the MVC paradigm is because the serialization you are doing is similar to the representation on the surface of the rendering based on the stream and displayed. Sometimes this can be done very smoothly in the model, but sometimes it is more complicated, and you need to look at your case to find out which one.

Often used transfer / web service code (or any other) will have its own handler for this data, for example ObjectiveResource adds a serialization and deserialization handler that works like an NSObject extension, which allows it to do a lot of this stuff transparently, and you can study this code (especially part of ObjectiveSupport) if you are trying to make this more general.

Answer 2

As a rule, almost all application code belongs to the controller. The controller must interact and observe (through notification) the model and, if necessary, update the view.

If you are processing the model in such a way that it is something that can be reused in another application with the same model, then this processing can be in the model.

Views can be laid out in Interface Builder or created in code and / or subclassed for a custom drawing, but they should not have application logic and will not interact directly with the model.

Answer 3

I would suggest putting serialization code in a model. If the process fails, it can report it no matter what it listens to (view / controller), which the UIAlertView can present, fix the problem and resubmit for another attempt.

Answer 4

I would say in the model.

The data serialization call will be performed by the controller. If the data cannot be serialized, then the model should return an error that the controller should process.