Das Beispiel im Buch verwendet ja einen ArrayController um die Daten im XIB zu managen. Später wird dann zwar eine Data-Source ausprogrammiert, aber die greift letztendlich zur Datenbeschaffung auch wieder auf die XIB-Datei zu. Mir kommt das ein bisschen wie von Hinten durch die Brust ins Auge vor, ist das wirklich eine gängige Methode? (XIB enthält den ArrayController der an den ManagedObjectContext gebunden ist, ein Control (im Beispiel der OutlineView) bekommt seine Daten von einer Data-Source, die aber ihrerseits wieder den ArrayController befragt).
Mir kommt das ein wenig wie eine Verletzung des MVC-Design Pattern vor, klar der ArrayController ist letztendlich auch ein "Controller". Aber wenn ich zum Beispiel heute ein Programm schreibe mit Speicherung der Daten via Core Data, und in einem Jahr möchte ich das umstellen so dass die Daten per XML-Austausch auf einem Server im Netz gespeichert werden sollen, würde ich bei Einhaltung der MVC Regeln erwarten dass ich für so eine Umstellung den Interface Builder nicht mehr starten muss - das wäre aber im beschriebenen Fall nicht gegeben.
Sauberer fände ich es also, wenn die anzuzeigenden Daten im Window- bzw. ViewController als Attribut gespeichert sind, oder per Data-Source (die vielleicht noch ausgelagert in eine eigene Klasse) zur Verfügung stehen. Dann könnte man im IB die entsprechende Anbindung machen, und wo die Daten herkommen ist dem View vollkommen egal.
Was für Möglichkeiten würde es denn geben den IB bei einer Data-Source für einen Outline-View aus der Datenbeschaffung ganz rauszuhalten? Einen NSArrayController programmatisch basteln und binden? Keinen ArrayController zu verwenden und alles per FetchRequest beschaffen? Oder wäre so eine Trennung eher unüblich und bringt zu viele Probleme mit sich?
Mir kommt das ein wenig wie eine Verletzung des MVC-Design Pattern vor, klar der ArrayController ist letztendlich auch ein "Controller". Aber wenn ich zum Beispiel heute ein Programm schreibe mit Speicherung der Daten via Core Data, und in einem Jahr möchte ich das umstellen so dass die Daten per XML-Austausch auf einem Server im Netz gespeichert werden sollen, würde ich bei Einhaltung der MVC Regeln erwarten dass ich für so eine Umstellung den Interface Builder nicht mehr starten muss - das wäre aber im beschriebenen Fall nicht gegeben.
Sauberer fände ich es also, wenn die anzuzeigenden Daten im Window- bzw. ViewController als Attribut gespeichert sind, oder per Data-Source (die vielleicht noch ausgelagert in eine eigene Klasse) zur Verfügung stehen. Dann könnte man im IB die entsprechende Anbindung machen, und wo die Daten herkommen ist dem View vollkommen egal.
Was für Möglichkeiten würde es denn geben den IB bei einer Data-Source für einen Outline-View aus der Datenbeschaffung ganz rauszuhalten? Einen NSArrayController programmatisch basteln und binden? Keinen ArrayController zu verwenden und alles per FetchRequest beschaffen? Oder wäre so eine Trennung eher unüblich und bringt zu viele Probleme mit sich?
Der Hintergrund ist aber, wie im Buch erläutert, dass ich nicht alles neu programmieren will. 
Wenn es üblich ist, dann mache ich es auch erstmal so. Will mir nicht gleich mein erstes echtes Projekt mit Frickeleien unnötig schwer machen. Für ein größeres Vorhaben welches aber noch nicht akut ist, werde ich mir dann aber nochmals die Alternativen anschauen. 