MVC - was darf das View wissen?

Christian Kienle · 6. Januar 2007, 09:26

Hallo,

ich habe neulich mit einem aus meiner Buddyliste versucht ein Cocoaproblem zu lösen.

Aufgabe war es ein View zu programmieren, welches Daten bildlich darstellt.

Mein Ansatz war, dem View ein member NSArray *dieDaten; zu verpassen und der Einfachheithalber das Ganze zu exposen.

Sein Ansatz war das View mit einem NSArrayController über ein Outlet bekannt zu machen (die Daten kamen alle von CoreData).

Dies hat mich in meinem Glauben etwas erschüttert.

Ist das nicht eine unnötige Konkretisierung des Sachverhaltes ein NSArrayController mit dem View bekannt zu machen oder muss ich mein Weltbild nun komplett überarbeiten?

hanswurst · 6. Januar 2007, 09:30

M: Model
V: View
C: Controller

M kennt C
V kennt C
M kennt nicht V!!

ich denke das vorhaben geht

Christian Kienle · 6. Januar 2007, 09:39

Wählt man die Datenquelle als NSArrayController und nicht nur als Array hat man halt den Nachteil, dass man immer - auch wenn man es nicht will einen Umweg über einen NSArrayController machen muss.

Es gibt ja durchaus den Falls, dass man das Backend austauschen will - man benutzt plötzlich mysql und nichtmehr core data (ja mysql ist eine Datenbank und core data ein objektgraph) - dann hat man unter umständen erstmal nur ein billiges array... daraus kann man sich natürlich ein NSArrayController basteln aber wozu gibts bindings?

Amin Negm-Awad · 6. Januar 2007, 10:46

Allso, ich gehöre ja eher zur Saubermann-Fraktion, soll heißen, dass ich eher fürs Prinzip bin. Aber man darf ja nicht vergessen, worum es geht:

MVC soll die unabhängige Verwertung und Wartbarkeit sichern. Selbständiige Einheiten statt Wollknäuel. Das bedeutet immer Abstraktion und damit immer Indirektion. So in etwa: Statt "Sag mir was X ist!" eher "Sag mir, wer mir sagen kann, was X ist!" Der Mittelmanns "wer" sichert dabei die Unabhängigkeit des Fragenden und Antwortenden.

Bei den großen Schichten des MVC bin ich da auch ziemlich strikt.

Bindings sichern dabei weniger die Unabhängigkeit, das macht ja jeder Controller. Es geht darum, die spezielle Implementierung des Controllers leicht und wiedervertbar zu halten. Ein Array-Controller, der ein bestimmtes Outlet hat, wirst du mutmaßlich nie wieder verwenden können. Wenn du ein Binding für ein View exposed, statt das View geradezu in den Startlöchern, demnächst wieder verwendet zu werden. Einfacher geht es ja nicht! 1 Zeile Sourcecode fürs Binding, eine fürs Unbinding!

Ich tendiere daher bei eigenen Views zu Bindings. Irgendwie kann man die immer noch einmal gebrauchen. Und schaue dir einfach mal an, wie häufig du bei Cocoa Views ableitest (1 von 3271 Views?) und wie das bei Frameworks ohne Bindings ist, mal von dem Synch-Kram ganz zu schweigen.

IIRC gehe ich das im Buch einmal komplett durch: Ein einfaches Programm (Bücherliste), welches zunächst ganz normal mit properitärem Controller aufgebaut wird und dann nach und nach durch Abstraktion immer schlanker wird. Du kannst zuschauen, wie der Sourcecode verschwindet.

Amin Negm-Awad · 6. Januar 2007, 10:51

Wenn das Model den Controller kennt, also typisiert kennt, istt es nur noch mit diesem Controller zu verwenden. Damit schießt du dir ziemlich ins Knie.

C kennt beide. M und V sollten nichts kennen. Systeme ohne Bindings, die irgendwelche Listen aktualisieren, kranken daran, dass der Programmierer des Modell darauf Rücksicht nehmen muss. Du brauchst dann irgendetwas wie [myController updateViewsForKey:@"name"]. Hält sich der Programmierer des Modells nicht daran, hast du ein Problem. Hast du nicht die Sourcen für das Model, ist es ein dickes Problem.

Das ist ja gerade das geniale an KVO: Es spielt keine Rolle, was für ein Scheiß der Programmierer des Models macht. Der Controller hängt sich an das Model und nicht umgekehrt. Und wennn man Bindings hat, wird das auch noch formalisiert.

Amin Negm-Awad · 6. Januar 2007, 10:53

Jepp, das war ja meine Idee bei dem Postgre-Kram. Statt eines Array-Controllers ein PG-Array-Controller. Und die Welt stimm wieder! Einmal programmiert, 231897123987181 {@Max stimmt wieder!) wiederverwendet.

Christian Kienle · 6. Januar 2007, 11:04

Damit hätten wir das auch geklärt.

Hatte ich also doch "recht".

Danke Tom.

Amin Negm-Awad · 6. Januar 2007, 11:43

Na ja, das ist ja keine "Ja/Nein"-Frage, mehr eine Wertung. Aber lieber etwas mehr Arbeit und dafür Wiederverwendung -- Das ist meine Einstellung.

Christian Kienle · 6. Januar 2007, 11:46

Ja aber sind wir nicht alle ganz tief in unserem Herzen kleine Recyclingfanatiker?

Amin Negm-Awad · 6. Januar 2007, 11:51

Hehehehehe, kompostierbarer Bio-Code. Ob das eine Auszeichnung ist?

Christian Kienle · 6. Januar 2007, 11:57

Es gibt Auszeichnungen für jeden Scheiss also bestimmt auch für "kompostierbarern Bio-Code". Das Öl wird immer knapper. Die Ölmultis immer frecher. Wir müssen uns von ihnen unabhängiger machen. Ein erster Schritt ist es mit dem, was wir haben vernünftig umzugehen. "kompostierbarer Bio-Code" ist ein erster Schritt in die richtige Richtung. Bestellen Sie sich nun die Broschüre vom Bundesamt für biologische, frühkindliche Erziehung und Aufklärung: Pro Wiederverwertbarkeit.