it-swarm.com.de

Was sind Repositorys, Services und Aktionen / Controller?

Ich habe ein Projekt mit Slim3 und PHP mit begrenzten Kenntnissen der Anwendungsarchitektur) gestartet. Der Plan war, das Projekt zu erstellen und Anwendungsprobleme zu trennen. Es lief alles gut, aber die Dinge wurden schnell verwirrend wie die Anwendung wuchs.

Die ganze Idee dafür war, die Entwicklung zu vereinfachen. Es funktioniert in gewisser Weise, aber ich finde es manchmal komplex, den Datenfluss im Auge zu behalten.

Ich benötige einige Ratschläge zu Repositorys, Services und Controllern/Aktionen. Und wie sie in einem System arbeiten sollen. Mein aktuelles Verständnis von ihnen ist unten:

Repository

Repositorys werden zwischen der Serviceschicht und der Modellschicht verwendet. In einem UserRepository würden Sie beispielsweise Methoden erstellen, die den Code zum Lesen/Schreiben aus der Datenbank enthalten. In PHP würde PDO oder ein ORM innerhalb der Repo-Methoden verwendet. Zum Beispiel:

class UserRepository
{
    public function findByID($id) { ... }
    public function findByEmail($email) { ... }
    public function findByMobile($mobile) { ... }
    public function createEmail($email, $firstname, $lastname, $password) { ... }
    public function createMobile($mobile, $firstname, $lastname, $password) { ... }
}

Ich habe dort einige Beispielmethoden eingefügt. Aber es würde wahrscheinlich noch viel mehr geben.

Dienste

Die Serviceschicht kapselt die Anwendungslogik. Zum Beispiel wäre UserService dafür verantwortlich, ein Konto zu erstellen und die erforderliche Logik auszuführen, um den Benutzer zu registrieren. Dienste können auch von Dritten bereitgestellt werden, z. B. zum Erstellen eines Dienstes für das SDK von Facebook oder für ORM.

Ein Beispieldienst:

class UserService
{
    public function createMobile($mobile, $firstname, $lastname, $password)     {
    /*
     * Call a validation service to validate input
     */
    ...

    /*
     * Use UserRepository's findByMobile() to check if account exists
     */
    ...

    /*
     * Use UserRepository's createMobile() to create account
     */
    ...

    /*
     * Call SMS service to send verification code
     */
    ...
    }

    public function createEmail(...) { ... }
    public function getFollowers (...) { ... }
}

Aktionen

Ich bin mir nicht sicher, ob dies ein richtiger Begriff ist. Es wird in der Slim Framework-Dokumentation verwendet und scheint einen Thin Controller darzustellen.

Eine Aktion enthält sehr wenig Logik und wird zum Aufrufen von Diensten verwendet. In seltenen Fällen ruft die Aktion die Repositorys direkt auf, es sei denn, es gibt einen gültigen Grund. Die Aktion führt grundlegende Überprüfungen der von den Diensten zurückgegebenen Daten durch, um eine Antwort an den Client zurückzusenden.

Sie sind an einzelne Routen gebunden. Ich benutze sie so:

class ActivateEmailAction extends Action {

    public function __invoke(Request $request, Response $response, $args = [])
    {
        if(!$this->ci->ActivationService->activateEmail($args['token'])){
            return $response->withJson([
                'status' => 'error',
                'data' => null,
                'message' => 'Invalid verification token'
            ]);
        };

        return $response->withJson([
            'status' => 'success',
            'data' => null,
            'message' => null
        ]);
    }
}

Benutze ich diese Muster richtig? Der Fluss, den ich angenommen zu haben scheint, ist wie folgt:

  1. Alles beginnt auf der Strecke. Zum Beispiel wird eine Anfrage an /create. Die Route ist für eine Aktion registriert.
  2. Die Aktion entscheidet, welche Dienste aufgerufen werden sollen
  3. Services führen die Logik aus und rufen bei Bedarf andere Services und Repositorys auf
  4. Der Dienst gibt Daten an die Aktion zurück
  5. Aktion gibt eine Antwort zurück

Jeder Rat wäre sehr dankbar.

7
BugHunterUK

Mir gefällt die Art und Weise, wie Sie dies umsetzen.

Einige Antworten:

Was sind Repositorys, Dienste und Aktionen/Controller?

  • Repositorys : Das Repository ist ein Gateway zwischen Ihrer Domänen-/Geschäftsschicht und einer Datenzuordnungsschicht, die auf die Datenbank zugreift und die Vorgänge ausführt. Grundsätzlich ist das Repository eine Abstraktion für Ihren Datenbankzugriff.

  • Service : Der Service sollte eine API für Ihre Geschäftslogik bereitstellen und daher eine Abstraktion für Ihr Repository darstellen. Hier bin ich nicht einverstanden, nur ein wenig, mit @Cerad sollten die Services die einzigen sein, mit denen Der Zugriff auf die Repositorys verstößt andernfalls gegen das Prinzip der Abhängigkeitsinversion (D in SOLID), da die Geschäftsschicht eine Abstraktion Ihrer Datenzugriffsschicht ist.

  • Aktionen/Controller : Die A/C-Objekte fungieren als Gateway zwischen Ihrer Eingabe und der Domänenlogik und entscheiden, was mit der Eingabe geschehen soll und wie die Antwort ausgegeben werden soll.

Ich finde es manchmal komplex, den Datenfluss im Auge zu behalten.

Ja, manchmal ist es so, aber wenn ich lese und mich nicht gut erinnere, dass es besser ist, organisierten und prinzipienbasierten Code zu haben, als letztere Schwierigkeiten mit hässlichem Code zu haben, macht es ihn handlicher, lesbarer und wartbarer.

Schließlich:

Das Architekturmodell, das Sie verwenden, ist die Ebenenarchitektur, alles ist in Ebenen getrennt, und die oberen Ebenen sind Abstraktionen der unteren. Deshalb sollte jede Ebene nur auf die unmittelbare untere Ebene verweisen.

Hoffe das hilft.

9
J. Pichardo