Take the 2-minute tour ×

When designing my application how many controllers should I have? Is it good practice to have one controller for the entire app, the entire window, or for each class? Additionally how many objects are to many created in the doc window in Interface Builder. Tutorials generally have one called AppController. Do full applications typically have App Controller or n*XYZController?

share|improve this question

2 Answers 2

up vote 4 down vote accepted

In a non-document-based app, one per window. I'm only talking about controllers you write yourself, not window controllers, view controllers, object controllers, array controllers, tree controllers, or dictionary controllers. (Note that some people do make their custom controller an NSWindowController.) I'm also not counting the app delegate, which owns your root controller(s).

In a single-window app, that usually means one custom controller.

In a document-based app, you generally don't write controllers at all, but write one or more NSDocument subclasses instead—one per document type. Each document object generally owns exactly one window.

Regardless of what kind of app you're writing, you may also want to make controllers for any floating utility panels (such as an Inspector) that you have, although you should consider the alternative: Make the panel be its own controller, as NSFontPanel and NSColorPanel are.

share|improve this answer

One per window, as Peter Hosey suggests is not a bad strategy, but one man's window is another woman's subview. I prefer to think in functional clusters: if there's two or more related things that need to be done, they might very well need a controller.

But, and this is crucial, you need to be able to think of a good name for your controller: importController, or textFilesImportController or externalFilesDisplayController are names that make clear what a particular controller will do and will not do.

If you cannot think of a good name for your controller take it as a sign that either you do not need it or you are still unclear about your design. In which case you may choose to call it your whateverController until your next flash of insight comes along.

share|improve this answer

Your Answer


