Bagaimana untuk membezakan antara logik perniagaan dan logik bukan perniagaan dalam pembangunan back-end dan melakukan reka bentuk berlapis yang munasabah?

Senibina hierarki back-end: Batasan yang jelas antara logik perniagaan dan logik bukan perniagaan

Dalam pembangunan back-end, seni bina tiga peringkat pengawal, perkhidmatan dan DAO tidak selalu cukup jelas. Artikel ini membincangkan bagaimana untuk membezakan secara berkesan antara logik perniagaan dan logik bukan perniagaan dalam perkhidmatan dan lapisan DAO, dan walaupun selepas memperkenalkan lapisan pengurus, untuk membina reka bentuk berlapis yang lebih munasabah.

Definisi antara logik perniagaan dan logik bukan perniagaan

Logik perniagaan secara langsung mengaitkan keperluan perniagaan, sementara tidak logik perniagaan bertanggungjawab untuk operasi yang mendasari, seperti akses data, pengesahan data, dan lain -lain sempadan kabur antara kedua -dua sering membawa kepada kekeliruan dalam kod.

1. Pengekalan operasi data: Sebagai contoh, UserManager.delete() dan DepartmentManager.delete() boleh mengendalikan penghapusan yang berkaitan dengan UserDeptModel pada masa yang sama. Ini adalah logik bukan perniagaan kerana ia memberi tumpuan kepada konsistensi data dan bukannya proses perniagaan itu sendiri. Contoh kod:

    Kelas Usermanager:
        def delete (diri, user_id):
            self.user_dao.delete (user_id)
            self.user_dept_dao.delete_by_user_id (user_id)
   
    Kelas Jabatan Kelas:
        def delete (diri, dept_id):
            self.dept_dao.delete (dept_id)
            self.user_dept_dao.delete_by_dept_id (dept_id)

2. Pemprosesan Keselamatan Data: Salting kata laluan dan operasi lain biasanya dilakukan di lapisan DAO atau pengurus, kerana ini adalah mekanisme perlindungan data, bukan logik perniagaan. Contoh kod (python dengan fungsi salt hipotetikal):

    USERDAO KELAS:
        def simpan (diri, pengguna):
            user.password = self.salt (user.password)
            # ... simpan pengguna ke pangkalan data ...
   
        def garam (diri, kata laluan):
            # ... Logik Salting Kata Laluan ...
            Kembalikan Salted_Password

3. Kaedah Layer DAO Penamaan Spesifikasi: Nama kaedah lapisan DAO harus mengelakkan termasuk makna perniagaan. Sebagai contoh, get_super_user() tidak jelas seperti get_user_by_type("super") .

4. Pengekalan panggilan perkhidmatan luaran: Jika backend bergantung kepada perkhidmatan luaran, panggilan ini harus dikemas pada lapisan DAO, bukan lapisan perkhidmatan, kerana ini adalah akses data, bukan logik perniagaan.

Simulasi fungsi penapis django

Di Python, jika tidak ada rangka kerja suntikan pergantungan, mengejek penapis Django memerlukan parameter permintaan pemprosesan di lapisan DAO dan lulus lapisan mereka dengan lapisan. Rangka Kerja Spring Java memudahkan proses ini.

Entiti data dan hubungan hierarki

Pengawal, Perkhidmatan dan DAO tidak sepadan dengan satu persatu. Tanggungjawab mereka adalah seperti berikut:

1. Pengawal: Kemasukan sistem, menerima dan proses proses, memastikan ia ringan.
2. Perkhidmatan: Lapisan pemprosesan logik perniagaan teras agak rumit.
3. DAO: Lapisan akses data hanya bertanggungjawab untuk interaksi data dan tidak termasuk logik perniagaan.

Sebagai contoh, "Buat Pengguna" Perniagaan: Lapisan Perkhidmatan melakukan "Periksa sama ada nama pengguna diduplikasi" dan "membuat pengguna"; Lapisan DAO menyediakan "pengguna pertanyaan berdasarkan nama pengguna" dan "simpan pengguna".

Dengan jelas membezakan logik perniagaan dari logik bukan perniagaan dan mengikuti reka bentuk berlapis yang munasabah, kebolehkerjaan dan skalabilitas kod dapat ditingkatkan.

Atas ialah kandungan terperinci Bagaimana untuk membezakan antara logik perniagaan dan logik bukan perniagaan dalam pembangunan back-end dan melakukan reka bentuk berlapis yang munasabah?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!