nicht angemeldet
Hi!
Ich habe das als Wartungsfreundlicher empfunden, außerdem verschwinden die SQL Statements aus meinem Code.
Man könnte zum Beispiel mal hergehen und alle SQL Statements auf Performance und Optimierung prüfen und hat sie so alle in einem Ordner vorhanden.
Ist wenig realistisch. "Heute optimiere ich mal alle Statements." :-) Eher kommt doch vor, dass du irgendwo einen Engpass siehst und diesen gezielt bearbeitest. Dann findest du dazu einen Bezeichner, musst anderenorts diesen Bezeichner wiedersuchen und das was eigentlich eng zusammenarbeiten soll hat ein paar Schnittstellen dazwischen, die Kosten verursachen - sei es Performance (wenn auch gering) oder insgesamt erhöhte Komplexität mit zweifelhaftem Nutzen.
Du kannst es aber gern mal auf deine Weise probieren, man lernt ja auch aus negativer Erfahrung. Andererseits kann sich dadurch auch was neues sinnvolles ergeben, das der Betriebsblinde sonst nicht erfahren würde.
Außerdem sieht man so besser wie viele Statements man in seinem Projekt verbaut hat.
Diese Information halte ich für wenig nützlich.
Genau das hatte ich eigentlich vor.
getData, setData, changeData, deleteData ... so in der Art.
Das wäre ja dann für jedes Model notwendig aber mit anderem Inhalt.
Nicht jedes Model hat genau je eine solche Methode. Die Models sind die Arbeiter in deiner Firma. Es mag einige geben, die Daten in allen 4 Facetten zu genau einem Thema verarbeiten. Andere haben mehrere (Teil-)Aufgaben oder komplett andere. Das Bodenpersonal räumt nur auf, der Wachschutz kontrolliert den Zugang zum Unternehmen, der Betriebsarzt kümmert sich um die Gesundheit, Einkauf und Vertrieb handeln mit externen Parteien und das Marketing sorgt fürs Brimborium.
Models müssen aber auch keine Universalmonster sein. Eine Model-Klasse kann auch Aufgaben delegieren. Wenn du Zeit und Muße hast, verweise ich nochmal auf ASP.NETs MVC-Implementation. Ganz unten steht eine Tutorial-Serie zu einem Contact-Manager. Vorab: Es ist nicht immer sinnvoll, alles anderswo gesehene 1:1 nach PHP übertragen zu wollen. Jedes System hat seine eigene Philosophie und andere Möglichkeiten, Dinge zu implementieren. In der erwähnten Tutorial-Serie jedenfalls ist in Interation 3 noch alles im Controller angesiedelt, in Iteration 4 werden Aufgaben in Service Layer und Repository ausgelagert, vor allem um sie kapseln und testbar machen zu können. Dort werden auch Interfaces verwendet, aber beispielsweise mit dem Ziel, auch mal einem Service-Layer ein Dummy-Repository unterjubeln zu können, damit Unit-Tests nicht vom Arbeitswillen eines DBMS abhängig sind, sondern sich ganz auf die eigentliche Aufgabe konzentrieren können. Service Layers und Repositorys behandeln jeweils ein Thema, aber es gibt keine generellen Basisklassen oder Interfaces, weil ihre Aufgaben doch zu verschieden sind.
Zum Beispiel eine View die ein Tabelle aus einem Array erzeugt. Das wäre doch etwas was sozusagen von jedem Model benutzt werden kann.
Das wäre meines Erachtens keine (eigenständige) View sondern eine Hilfsfunktion, derer sich eine View bedienen kann aber nicht muss. Und nicht alle vom Model erledigten Aufgaben erfordern eine tabellarische Darstellung des Ergebnisses. Ein Interface, das zu (großen) Teilen wegen Nichtverwendung nicht implementiert ist, ist auch nicht sehr sinnvoll.
Ein Datagrid, ein Pager, ein Formulargenerator - alles Funktionalität, die zwar öfter verwendet wird, aber nicht zwangsläufig. Dafür muss also nicht überall eine Vorbereitung getroffen werden.
Lo!