Wie kann man zwischen Geschäftslogik und Nicht-Business-Logik in der Back-End-Entwicklung unterscheiden und ein angemessenes geschichtetes Design durchführen?

Hierarchische Architektur Back-End: Klare Grenzen zwischen Geschäftslogik und Nicht-Business-Logik

In der Back-End-Entwicklung sind die gemeinsamen dreistufigen Architekturen von Controller, Service und DAO nicht immer klar genug. In diesem Artikel wird erläutert, wie man effektiv zwischen Geschäftslogik und Nicht-Business-Logik im Dienst und DAO-Ebenen sowie nach der Einführung der Manager-Ebene unterscheidet, um ein vernünftigeres Design aufzubauen.

Definition zwischen Geschäftslogik und Nicht-Geschäft-Logik

Die Geschäftslogik bezieht die Geschäftsanforderungen direkt, während keine Geschäftslogik für zugrunde liegende Operationen wie Datenzugriff, Datenüberprüfung usw. verantwortlich ist.

1. Einkapselung von Datenoperationen: Zum Beispiel können UserManager.delete() und DepartmentManager.delete() gleichzeitig die zugehörige Löschung von UserDeptModel verarbeiten. Dies ist eine Nicht-Business-Logik, da sie sich eher auf die Datenkonsistenz als auf den Geschäftsprozess selbst konzentriert. Codebeispiel:

    Klasse UserManager:
        Def delete (self, user_id):
            self.user_dao.delete (user_id)
            self.user_dept_dao.delete_by_user_id (user_id)
   
    Klassenabteilungsinstitut:
        def delete (self, Dept_id):
            self.dept_dao.delete (Dept_id)
            self.user_dept_dao.delete_by_dept_id (Dept_id)

2. Datensicherheitsverarbeitung: Kennwortsalzierung und andere Vorgänge werden normalerweise bei DAO oder Manager Layer durchgeführt, da dies ein Datenschutzmechanismus ist und keine Geschäftslogik. Code -Beispiel (Python mit hypothetischer salt ):

    Klasse Userdao:
        Def Save (Selbst, Benutzer):
            user.password = self.Salt (user.Password)
            # ... Benutzer in der Datenbank speichern ...
   
        Def Salt (Selbst, Passwort):
            # ... Passwort Salzlogik ...
            return salted_password

3. DAO -Schichtmethode Benennungspezifikation: DAO -Schichtmethodennamen sollten vermeiden, geschäftliche Bedeutungen einzubeziehen. Zum Beispiel ist get_super_user() nicht so klar wie get_user_by_type("super") .

4. Externe Service Call -Kapselung: Wenn das Backend von externen Diensten abhängt, sollten diese Anrufe in der DAO -Ebene und nicht in der Serviceschicht eingekapselt werden, da dies Datenzugriff und keine Geschäftslogik ist.

Simulieren Sie die Django -Filterfunktion

Wenn in Python kein Abhängigkeitsinjektionsgerüst vorliegt, erfordert der verspottete Django -Filter die Verarbeitungsanforderungsparameter in der DAO -Schicht und überlagern Sie sie für Schicht. Javas Spring Framework vereinfacht diesen Prozess.

Datenentität und Hierarchiebeziehung

Controller, Service und DAO entsprechen nicht nacheinander. Ihre Verantwortlichkeiten sind wie folgt:

1. Controller: Systemeintrags-, Empfangs- und Prozessanfragen und leichte Halten.
2. Service: Die Core Business Logic -Verarbeitungsschicht ist relativ komplex.
3. DAO: Die Datenzugriffsschicht ist nur für die Dateninteraktion verantwortlich und enthält keine Geschäftslogik.

Zum Beispiel "Benutzer erstellen" Business: Die Serviceschicht führt "Überprüfen Sie, ob der Benutzername dupliziert ist" und "Benutzer erstellen". Die DAO -Ebene enthält "Abfragen von Benutzern basierend auf dem Benutzernamen" und "Benutzer speichern" Methoden.

Durch die deutliche Unterscheidung der Geschäftslogik von der Nicht-Business-Logik und nach einem angemessenen Schichtdesign können die Wartbarkeit und Skalierbarkeit des Codes verbessert werden.

Das obige ist der detaillierte Inhalt vonWie kann man zwischen Geschäftslogik und Nicht-Business-Logik in der Back-End-Entwicklung unterscheiden und ein angemessenes geschichtetes Design durchführen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!