Wie kann ich die Geschäftslogik und die Nicht-Business-Logik in der hierarchischen Architektur in der Back-End-Entwicklung korrekt teilen?

Hierarchische Architektur Back-End

In der Back-End-Entwicklung ist eine geschichtete Architektur (z. B. Controller, Service und DAO-Schichten) von entscheidender Bedeutung. Obwohl das Hierarchieprinzip klar ist, sind in der Praxis, insbesondere die Grenzen zwischen der Serviceschicht und der DAO -Schicht sowie der logischen Teilung nach der Einführung der Managerschicht, oft verwirrend. In diesem Artikel wird untersucht, wie wir zwischen Geschäftslogik und Nicht-Business-Logik effektiv unterscheiden können.

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

Die Geschäftslogik bezieht sich direkt auf geschäftliche Anforderungen, die Benutzer wahrnehmen können. Während Nicht-Business-Logik eine zugrunde liegende Operation ist und nichts mit Geschäftsprozessen zu tun hat, wie z. B. Datenbankbetriebsdetails oder Kennwortverschlüsselung.

Hier sind einige Beispiele für die Logik der Nicht-Business:

1. Datenbankbetriebsdetails: UserManager.delete() und DepartmentManager.delete() können Daten in Assoziations -Tabellen (z. B. userdeptmodel ) gleichzeitig löschen. Dies ist eine Logik ohne Geschäft, da sie nur Datenbankoperationen umfasst, nicht um Geschäftsprozesse selbst. Ohne die Manager -Ebene kann die DAO -Ebene auch solche Vorgänge bewältigen, solange sie nichts mit dem Geschäft zu tun hat.

    Klasse UserManager:
        def delete (self):
            userdao.delete ()
            userdeptdao.delete ()
   
    Klassenabteilungsinstitut:
        def delete (self):
            Abteilungdao.delete ()
            userdeptdao.delete ()

2. Kennwortverschlüsselung: Benutzer müssen die Details des Kennwortspeichers nicht kennen, und der Salzvorgang kann in der DAO- oder Manager -Ebene platziert werden.

    Klasse Userdao:
        Def make_password (self, passwd):
            Return Salt (Passwd) # Angenommen, die Salzfunktion wird zum Hinzufügen von Salz zum Passwort def Save (Selbst) verwendet:
            passwd = self.make_password (Passwd)
            self.passwd = passwd
            Super (). Save () #Suppose Super (). Save () ist eine Datenbank -Speichermethode

3. DAO -Layer -Methode Benennung: Ob ein Methodenname wie get_super_user geeignet ist, hängt davon ab, ob es sich um eine Geschäftslogik handelt. Wenn super nicht geschäftsbedingt ist, kann es verwendet werden. Andernfalls sollte es auf der Servicestufe behandelt werden.

4. HTTP-Anforderungskapselung: Die Backend-abhängige Kapselung kann in der DAO-Ebene anstelle der Serviceschicht platziert werden.

Implementieren Sie Funktionen ähnlich dem Django -Filter in Python

In Django/Flask ist die Datenfilterung relativ einfach. In der dreischichtigen Architektur von Python muss jedoch überlegen, wie die Anforderungen Parameter in der DAO-Schicht verarbeitet werden. Wenn es kein Abhängigkeitsinjektionsgerüst wie Frühling gibt, müssen die Parameter manuell übergeben werden. In Java bieten ORM -Frameworks wie Hibernate leistungsstarke Datenfilter- und Abfragefunktionen.

Datenentitäten und hierarchische Architektur

Datenentitäten werden für die Datenpersistenz verwendet. In einer dreischichtigen Architektur entsprechen der Controller-, Service- und DAO-Schichten nicht nacheinander der einzigen. Die Serviceschicht kann mehrere DAOs anrufen, um einen Geschäftsbetrieb abzuschließen, und ein DAO kann auch von mehreren Diensten aufgerufen werden.

Kurz gesagt, die korrekte Unterscheidung der Geschäftslogik von der Nicht-Business-Logik ist der Schlüssel zur Back-End-Entwicklung, und eine angemessene hierarchische Architektur kann die Lesbarkeit und Wartbarkeit der Code verbessern.

Das obige ist der detaillierte Inhalt vonWie kann ich die Geschäftslogik und die Nicht-Business-Logik in der hierarchischen Architektur in der Back-End-Entwicklung korrekt teilen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!