Ich versuche eine Clean-Cut-Service-Schicht zu erstellen, wobei die Service-Schicht auf ein oder mehrere Repositories einwirkt und jedes Repository auf sein eigenes redegewandtes Modell einwirkt.
Zum Beispiel könnte ich haben:
%Vor% Jeder Dienst definiert seine erforderlichen Abhängigkeiten über ioc . So etwas wie:
Meine Repositories werden über ihre Bindungen in ihren jeweiligen Dienstanbietern aufgelöst, z. B .:
%Vor%Das alles funktioniert gut. Jeder Dienst erhält die benötigten Repositories.
Um die Service-Schicht von jeder spezifischen eloquenten Abhängigkeit freizuhalten, ist alles, was ein Repo verlässt, ein einfaches, unveränderliches Datenobjekt.
Wichtige Punkte in der Alltagssprache:
Jedoch Ich kann kein sauberes Muster für associate eloquente Modelle in der Service- oder Repo-Ebene erstellen.
Wenn das Post -Modell eine belongsTo(User::class) -Beziehung aufweist, wie kann ich diese Beziehung auf der Repository-Ebene Post sauber erstellen.
Ich habe es versucht:
%Vor% Aber associate erwartet ein user eloquentes Objekt, nicht nur eine ID. Ich könnte tun:
Aber ich fühle mich, als ob ich ein eloquentes Modell in ein Repo tauche, das nicht darauf handeln sollte.
Der einfache Weg:
%Vor% Nun bedeutet das, dass Sie den Fremdschlüssel author_id der Relation kennen. Um es ein wenig zu abstrahieren, benutze das:
Beachten Sie, dass Sie immer noch save das $post -Modell benötigen, aber ich nehme an, dass Sie das bereits wissen.
Abhängig von Ihrer Implementierung des einfachen, unveränderlichen Datenobjekts , das Sie verwenden, können Sie auch zulassen, dass die Objekte anstelle von rohen IDs übergeben werden. Etwas zwischen den Zeilen:
%Vor% Was ich in der Vergangenheit getan habe, was mir eine gewisse Vernunft gebracht hat, war, dass Sie ähnliche Dinge wie in Ihrer zweiten associate -Methode tun und das Repository mit Eloquent voranstellen, damit ich im Fall I benutze etwas außer Eloquent , ich erstelle nur eine neue Implementierung des Repository.
In diesem Fall würde ich also mit class EloquentUserRepository implements UserInterface enden. Normalerweise habe ich am Ende einige öffentliche Methoden, die nur Primitive und möglicherweise einige private Methoden annehmen und zurückgeben, die an Eloquent gekoppelt wären. Also mache ich dann diese öffentlichen Methoden in eine AbstractUserRepository oder eine Eigenschaft, wenn sie mehr macht Sinn, den Code DRY zu behalten.
Es hängt wirklich von der Situation ab, ich hatte viele Gedanken über diese Aktionen und auch über meine Repositories.
Was ich vorschlagen würde, ist einfach nicht die "Associate" -Funktion zu verwenden, Sie können einfach tun:
%Vor%** Natürlich müssen Sie sicherstellen, dass der Benutzer mit dieser ID existiert.
A) Sie können es draußen mit einem speziellen Service für "associatingUser" tun B) Sie können es so machen, wie Sie es mit dem UserRepositoryInterface getan haben, Ich sehe kein Problem, die Schnittstelle als Abhängigkeit hinzuzufügen.
Option A:
%Vor%Option B (ziemlich genau, der Code sitzt nur an verschiedenen Stellen)
%Vor%Hydration!
Ich gehe davon aus, dass ein weiterer Grund für das Aufrufen von findEloQuent im Post-Dienst icky ist, weil Sie diese Daten möglicherweise bereits innerhalb des Controllers abgerufen haben. Einfach gesagt, Sie können auf die gleiche Methode zugreifen, die Eloquent verwendet, um rohe Abfrageergebnisse in voll funktionsfähige Modelle zu transformieren.
%Vor%Ich denke, dass Sie tatsächlich eine zusätzliche Schicht benötigen, ist, was ich einen Manager nenne. Dies wird die gesamte Geschäftslogik enthalten und nur mit Schnittstellen funktionieren. Unter der Haube ruft es die Dienste an (jeder weiß, dass er mit einer bestimmten Ressource / einem bestimmten Modell arbeiten soll)
Tags und Links repository-pattern laravel eloquent service-layer