Bagaimana cara membahagikan logik perniagaan dan logik perniagaan dengan betul dalam seni bina hierarki dalam pembangunan back-end?

Senibina hierarki back-end: bijak membahagikan logik perniagaan dan logik bukan perniagaan

Dalam pembangunan back-end, seni bina berlapis (contohnya, pengawal, perkhidmatan, dan lapisan DAO) adalah penting. Walaupun prinsip hierarki jelas, dalam amalan, terutama sempadan antara lapisan perkhidmatan dan lapisan DAO, serta pembahagian logik selepas pengenalan lapisan pengurus, sering mengelirukan. Artikel ini akan meneroka bagaimana untuk membezakan secara berkesan antara logik perniagaan dan logik bukan perniagaan.

Definisi antara logik perniagaan dan logik bukan perniagaan

Logik perniagaan secara langsung berkaitan dengan keperluan perniagaan, yang pengguna dapat melihat; Walaupun logik bukan perniagaan adalah operasi asas dan tidak ada kaitan dengan proses perniagaan, seperti butiran operasi pangkalan data atau penyulitan kata laluan.

Berikut adalah beberapa contoh logik bukan perniagaan:

1. Butiran operasi pangkalan data: UserManager.delete() dan DepartmentManager.delete() boleh memadamkan data dalam jadual persatuan (seperti userdeptmodel ) pada masa yang sama. Ini adalah logik bukan perniagaan kerana ia hanya melibatkan operasi pangkalan data, bukan proses perniagaan sendiri. Tanpa lapisan pengurus, lapisan DAO juga boleh mengendalikan operasi sedemikian, selagi ia tidak ada kaitan dengan perniagaan.

    Kelas Usermanager:
        def delete (diri):
            userdao.delete ()
            userDeptdao.delete ()
   
    Kelas Jabatan Kelas:
        def delete (diri):
            jabatandao.delete ()
            userDeptdao.delete ()

2. Penyulitan Kata Laluan: Pengguna tidak perlu mengetahui butiran penyimpanan kata laluan, dan operasi garam boleh diletakkan di lapisan DAO atau pengurus.

    USERDAO KELAS:
        def make_password (diri, passwd):
            Kembalikan garam (passwd) # menganggap bahawa fungsi garam digunakan untuk menambah garam ke kata laluan def simpan (diri):
            passwd = self.make_password (passwd)
            self.passwd = passwd
            Super (). Simpan () #Suppose Super (). Simpan () adalah kaedah Simpan pangkalan data

3. Kaedah Layer DAO Penamaan: Sama ada nama kaedah seperti get_super_user sesuai bergantung kepada sama ada ia melibatkan logik perniagaan. Jika super tidak berkaitan dengan perniagaan, ia boleh digunakan; Jika tidak, ia harus ditangani di lapisan perkhidmatan.

4. Permintaan HTTP enkapsulasi: enkapsulasi yang bergantung kepada backend boleh diletakkan di lapisan DAO dan bukannya lapisan perkhidmatan.

Melaksanakan fungsi yang serupa dengan penapis django di python

Dalam Django/Flask, penapisan data agak mudah. Walau bagaimanapun, dalam seni bina tiga lapisan Python, perlu mempertimbangkan bagaimana memproses parameter permintaan di lapisan DAO. Sekiranya tidak ada kerangka suntikan ketergantungan seperti musim bunga, parameter perlu diluluskan secara manual. Di Java, rangka kerja ORM seperti Hibernate menyediakan penapisan data yang kuat dan fungsi pertanyaan.

Entiti data dan seni bina hierarki

Entiti data digunakan untuk kegigihan data. Dalam seni bina tiga lapisan, pengawal, perkhidmatan dan lapisan DAO tidak sesuai dengan satu demi satu. Lapisan perkhidmatan boleh memanggil pelbagai DAO untuk menyelesaikan operasi perniagaan, dan DAO juga boleh dipanggil oleh pelbagai perkhidmatan.

Ringkasnya, logik perniagaan yang membezakan dengan betul dari logik bukan perniagaan adalah kunci untuk pembangunan back-end, dan seni bina hierarki yang munasabah dapat meningkatkan kebolehbacaan kod dan kebolehkawalan.

Atas ialah kandungan terperinci Bagaimana cara membahagikan logik perniagaan dan logik perniagaan dengan betul dalam seni bina hierarki dalam pembangunan back-end?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!