MVC design pattern in complex iPad app: is one fat controller acceptable?

I am building a complex iPad application; think of it as a scrapbook. For the purpose of this question, let's consider a page with two images over it.

My main view displays my doc data rendered as a single UIImage; this because I need to do some global manipulation over them. This is my DisplayView.

When editing I need to instantiate an EditorView with my two images as subviews; this way I can interact with a single image, (rotate it, scale it, move it). When editing is triggered, I hide my DisplayView and show my EditorView.

In a iPhone app, I'd associate each main view (that is, a view filling the screen) to a view controller.

The problem is here there is just one view controller; I've considered passing the EditorView via a modal view controller, but it's not an option (there a complex layout with a mask covering everything and palettes over it; rebuilding it in the EditorView would create duplicate code).

Presently the EditorView incorporates some logic (loads data from the model, invokes some subviews for fine editing, saves data back to the model); EditorView subviews also incorporate some logic (I manipulate images and pass them back to the main EditorView). I feel this logic belongs more to a controller. On the other hand, I am not sure making my only v开发者_如何学Goiew controller so fat a good idea.

What is the best, cocoa-ish implementation of such a class structure?

Feel free to ask for clarifications.

Cheers.

Huge fat controllers are fine.

If necessary, just break off some "purely logical parts" from it and shove them in other "helper classes". And use tricks like categories extensively where you can.

Definitely go with a HFC (huge fat controller) if that feels right.

Then, just get on your engineering bike and slim the hell out of it!

You should definitely not avoid the right structure, the good structure, the structure you want, just because one thing will be too big.

Just slim that big thing down by outsourcing concepts, going nuts with categories, etc etc - every trick in the book.

My belief!

Some reasons to wrap a viewcontroller around your view:

• to use it in an Apple API that requires a viewcontroller (popover views, modal views, navigation bars, tab bars, ...)

• because the view can be invisible for a while, and so it makes sense to clean it up in low memory situations. The viewcontroller then guards the data that needs to survive such an unload-reload cycle.

• because you just like the MVC pattern

I think the second bullet justifies a viewcontroller for your editable content view and another one for your non-editable content view.