Wie schreibt man wiederverwendbare Geschäftslogik in MVC-Modellen?

Question

Mein Problem ist, dass wir versuchen, ein MVC (PHP) Framework zu verwenden. Nach vielen Diskussionen denke ich, dass MVC sehr gut ist, aber mir fehlt die Möglichkeit, wiederverwendbare Modell- (Anwendungs-) Logik zu schreiben. Ich bin also nicht sicher, ob wir den richtigen Ansatz zur Implementierung unserer Software in einem MVC-Framework haben.

Zuerst beschreibe ich den nicht-MVC, oo-Ansatz, den wir im Moment verwenden.

Zum Beispiel - wir arbeiten an einigen Browsergames (ja, das ist unser Beruf). Stellen Sie sich vor, wir haben ein Spielerobjekt. Wir benutzen dieses Spielerobjekt sehr oft. Wir haben verschiedene Seiten, auf denen Sie nachdenken können, also müssen Sie "Geld" -Transaktionen auf dem Bankkonto des Spielers machen oder sich vorstellen, dass Sie gegen andere Spieler kämpfen können. Wir haben mehrere Kampf-Skripte, und diese Skripte nehmen 2 oder mehr Spieler-Objekte auf (es hängt von der Art des Kampfes ab, dh Clan-Kampf, Spieler-gegen-Spieler-Kampf ...).

Also, wir haben mehrere Seiten (und Controller) mit unterschiedlicher Kampflogik. Aber jeder dieser Controller verwendet das Spieler-Objekt, um alle Attribute und Gegenstände eines Spielers zu berechnen und welche Schaden und Verteidigung ein Spieler macht.

Also, wie können wir die Logik im Player-Objekt im Falle eines MVC-Modells wiederverwenden? es wäre schlecht, die ganze notwendige Logik in den verschiedenen Kampfkontrollern und -modellen zu kopieren.

Ich denke, die "gold-transaction" -Logik wäre ein gutes Beispiel, um Ihnen weitere Detailinformationen zu geben. du brauchst die transact-funktion im falle eines kampfes, wenn du gegen einen anderen spieler gewinnst und etwas von seinem gold erbeutest, brauchst du die transaktionsfunktion, wenn du etwas kaufst und du benötigst die transact-funktion, wenn du etwas gold ausgibst an die Spielergilde ...

Also würde ich sagen, es wäre ein schlechter Ansatz, all diese Funktionen in einem Spielermodell zu definieren! Ich kann dir sagen, dass dieses Player-Modell sehr groß sein würde (eigentlich haben wir das Problem, dass unsere Player-Klasse wirklich riesig ist - es ist eine Gott-Klasse)

Denkst du, es gibt eine MVC-ähnliche Lösung für dieses Problem?

Answer 1

Ich würde sagen, Sie setzen den Code, wo es am sinnvollsten ist, und wo Sie es an einem anderen Ort nicht duplizieren müssten.

Wenn es eine Operation gibt, die immer ein Player-Objekt benötigt, aber möglicherweise über verschiedene Controller hinweg verwendet wird, wäre die Player-Klasse der logische Ort, um sie zu platzieren. Auf der anderen Seite, wenn ein bisschen Logik nur im Zusammenhang mit einem bestimmten Controller ausgeführt werden muss und potenziell andere Klassen beinhaltet, sollte es vielleicht im Controller sein - oder vielleicht auch in einer anderen Klasse.

Wenn Sie Probleme haben, herauszufinden, wo die Logik gehen sollte, liegt das vielleicht daran, dass Ihre Funktionen nicht granular und wiederverwendbar genug sind, wie sie sind. Es gibt sicherlich Aspekte von MVC, die Sie zwingen, ein wenig mehr über die Trennung von Bedenken zu denken und DRY mehr zu halten als einen "einfachen" OOP-Ansatz ... damit Sie möglicherweise die aktuell kodierten Operationen, die in einem einzigen Fall sind, aufbrechen Funktionieren Sie jetzt in mehreren Funktionen in verschiedenen Klassen, um den richtigen Code an den richtigen Stellen zu erhalten.

Zum Beispiel - und das sind keine spezifischen Vorschläge, sondern nur ein zufälliger möglicher Denkprozess - vielleicht muss der Prozess der Übertragung von "Gold" zwischen Spielern in granularere Prozesse unterteilt werden. Die Spielerklasse kann die grundlegende Aufgabe übernehmen, das Gleichgewicht zu ändern, aber dann können die Controller bestimmte Teile des Prozesses ausführen, wie z. B. überprüfen, von wem oder von wem Gold transferiert wird und warum.