An Introduction to Cocoa Bindings
Most tutorials teach you how to use bindings with Interface Builder. While this is by far the most common way to use bindings, Interface Builder can leave the impression that bindings are a kind of magic, and developers who never dive deeper and gain a full understanding of how they work can often struggle to solve certain problems, especially when trying to debug some unexpected behaviour.
[…]
There are benefits if the object being bound to implements NSEditorRegistration. This is one reason why it’s a good idea to bind to controller objects rather than binding directly to the model. NSEditorRegistration lets the binding tell the controller that its content is in the process of being edited. The controller keeps track of which views are currently editing the controller’s content. If the user closes the window, for example, every controller associated with that window can tell all such views to immediately commit their pending edits, and thus the user will not lose any data.
[…]
In bindings, the view does all the work. It is responsible for observing the model, pushing its own changes back to the model (using Key Value Coding) at an appropriate point, and keeping track of all the information about the binding. If you’re binding to Apple-supplied views (or Apple-supplied controllers that expose bindings) all this is taken care of, but it becomes important if you are creating your own bindable views.
