it-swarm.com.de

Warum werden Methoden in Modellen und Controllern in Joomla zufällig platziert?

Ich bin ziemlich neu in Joomla. Ich habe jetzt die Sache mit Komponenten, Modulen und Vorlagen verstanden und kann auch Module und einfache Komponenten erstellen.

Aber das einzige, was mich in Joomla immer verwirrt hat, ist die Platzierung von Methoden in Komponenten. Ich habe ein System studiert und festgestellt, dass die Speicherfunktion manchmal im Modell und manchmal in Controllern überschrieben wird. Die Online-Lösungen für Abfragen variieren ebenfalls. Einige schlagen vor, Methoden im Modell zu platzieren, während andere im Controller angeben. Was ich denke, ist, dass das Modell keine solchen Methoden haben sollte, bei denen eine zusätzliche Logik ausgeführt werden sollte, und es ist der Controller-Job.

Oder welches Muster fehlt mir hier in dieser Hinsicht, bitte klären Sie mich auf.

2
Raavan

Der Kommentar von @mickmackusa ist im Wesentlichen korrekt, aber in Ihrer Frage fehlt möglicherweise ein Kontext, der mich fragen lässt, ob Sie keine umfassendere Frage stellen. Es gibt eine Vielzahl von Gründen für die Überschreibungen, die Sie sehen.

In einer MVC-Welt ist "Speichern" sowohl ein Controller nd eine Modellmethode. Es ergibt sich aus dem Konzept "Trennung von Bedenken". Das Anliegen des Modells besteht nicht darin, mit dem Rest des Systems zu interagieren. Es geht darum, sicherzustellen, dass die Daten gültig sind, und sie dann beizubehalten.

Wenn Sie mit dem System interagieren, erhält der Controller zuerst die Anforderung "Speichern" von Ihnen, und er muss möglicherweise eine eigene Verwaltung durchführen, bevor er die Anforderung an das Modell weiterleitet. Wenn dies der Fall ist, muss die Speichermethode des Controllers überschrieben werden, um dies zu erreichen.

Ein weiterer möglicher Grund ist, dass das übermittelte Formular selbst Daten von zwei verschiedenen Modellen enthalten kann (oder für diese bestimmt ist). Das ist vom Standpunkt der reinen Codierung nicht "sauber", aber wir leben und arbeiten in der realen Welt mit realen Benutzern, die nicht mit drei verschiedenen Formen umgehen möchten, nur weil dies eine effizientere Art ist, die Daten zu speichern - a Benutzererfahrung sollte niemals als Sklave der Datenbank sein. In diesen Fällen stellt die Aufgabe "Speichern" des Controllers sicher, dass die Daten an das richtige Modell weitergeleitet werden. Dieser Ansatz kann auftreten, wenn Sie Ihr System auf den Aufgaben des Benutzers und nicht auf den Datenbanktabellen aufbauen. (Ich kommentiere nicht, welcher Ansatz der bessere ist, weil es ehrlich gesagt keine eindeutige Entscheidung ist. Es gibt Fälle, in denen einer besser ist als der andere.)

Ein weiterer Grund für das Überschreiben der Methode ist, dass die Klasse selbst dem Prinzip der Einzelverantwortung nicht sehr gut folgt (in direktem Zusammenhang mit dem Kommentar "aus vielen Lebensbereichen"). Es gibt mehrere Methoden, die wirklich in 5-6 kleinere Methoden unterteilt werden sollten. Die große Methode wird häufig überschrieben, da nur eine einzige Zeile, die manchmal nur vage mit der Aufgabe zusammenhängt, geändert werden muss.

Es gibt eine Denkschule namens "Skinny Controller - Fat Model", die besagt, dass alles, was mit den Daten zu tun hat, zum Modell gehört. Der Controller ist eine verherrlichte Schalttafel, die einfach sicherstellt, dass das Modell die Daten erhält, die es benötigt. Es gibt andere Schulen, die darauf bestehen, dass es andere Klassen rund um das Modell und den Controller geben muss, die sich um die Geschäftslogik kümmern. Die Steuerung steuert und das Modell speichert, und andere Klassen erledigen die anderen Dinge. Es gab wirklich nie einen Architekten, der sagte "das muss hier hingehen", also haben wir das, was wir haben; tausend verschiedene Blumen blühen im Code. MVC war noch nie so streng definiert, dass Code nur auf eine Weise geschrieben werden kann, um ihn zu befriedigen (einer der frühen MVC-Ansätze gab beispielsweise jedem einzelnen Bereich auf dem Bildschirm einen eigenen Controller; ich erinnere mich, dass jemand diese Idee vor einiger Zeit wiederbelebt hat unter dem Namen "Hierarchical Model-View-Controller").

All dies dient dazu, den Kontext dafür bereitzustellen: Ihre Frage enthält wirklich nicht genügend Informationen, um eine konkrete Antwort zu erhalten. Wenn Sie etwas im Code sehen und das Warum nicht verstehen, stellen Sie eine bestimmte Frage zu diesem Teil. Vielleicht gibt es einen guten Grund, warum die allgemeine Regel in diesem Fall nicht gilt. Vielleicht lautet die richtige Antwort "Ups. Du hast Recht. Das gehört nicht dorthin."

In diesem Fall haben Sie möglicherweise gerade Ihre erste Gelegenheit gefunden, einen Beitrag zum Projekt zu leisten.

1
Arlen