Terima kasih atas jemputan! Tetapi saya perlu mengisytiharkan bahawa saya bukan pakar |_|

Soalan: Adakah pendekatan saya terhadap lapisan dao dan lapisan perkhidmatan dalam langkah 1, 2 dan 3 di atas munasabah? Mana satu lebih baik, 2 atau 3?

Pertama sekali, saya bersetuju dengan analisis dan pemahaman anda dalam langkah 1, 2 dan 3. Kedua, saya fikir pemprosesan 3 adalah lebih sesuai, kerana lapisan service bukan lagi interaksi data tulen, tetapi mengandungi satu siri operasi logik perniagaan Dengan menangkap Throwable dan kemudian membuang Pengecualian yang lebih bermakna (. yang boleh menerangkan ralat dengan tepat), sama ada direkodkan dalam log atau pemprosesan transaksi, adalah lebih sesuai untuk kemungkinan penyelesaian masalah/ralat berikutnya

4 Meneruskan daripada perkara di atas, ke tahap apakah perincian pengecualian perniagaan tersuai ini harus dikawal? Boleh beri saya contoh

Kebutiran bergantung pada keperluan Sebagai contoh, jika anda hanya mahu melakukan rollback, maka selagi anda dapat mengesan apa yang service salah, itu sudah memadai untuk anda. Tetapi jika anda masih mahu menyelesaikan masalah selanjutnya root cause, bukankah lebih baik untuk memasukkan lebih banyak penerangan tentang ralat sumber dalam mesej pengecualian?

5 Dalam 2 dan 3 di atas, saya menggunakan aop untuk mengendalikan pengecualian secara seragam. Saya rasa kebanyakan orang mengesyorkan ini. Kerana logik dalam tangkapan dalam setiap kaedah lapisan perkhidmatan kebanyakannya serupa. Faedah menggunakan aop untuk pemprosesan bersatu adalah jelas. Saya ingin tahu, adakah terdapat kekurangan? Kerana saya mendapati hampir tiada projek syarikat melakukan ini. Kesemuanya adalah cubaan tangkap langsung dan hasil pulangan. Atau ia bukan tangkapan yang disebut dalam 2 di atas. Jika pengecualian berlaku, ia boleh direkodkan dalam log

Pertama sekali, mari kita bincangkan tentang sebab syarikat anda tidak berbuat demikian. Ini mungkin disebabkan oleh sebab sejarah Orang yang membina rangka kerja sebelum ini tidak cukup mengetahui tentang aop, atau mereka membawa pilihan peribadi mereka. bekerja dan memilih untuk pergi terus ke mana-mana try catch(kaedah ini Mudah dan kasar, paling mudah dikuasai), aop dianggap sebagai paradigma reka bentuk sama ada arkitek atau pengaturcara, mereka masih perlu belajar untuk menguasainya dan menggunakannya secara bebas (ini mungkin merugikan). Jika anda berminat dengan sebabnya, sebaiknya berbual dengan beberapa rakan sekerja senior secara tertutup, mungkin anda boleh mendapatkan maklumat dalaman yang lain^^

Mengenai "sebarang pengecualian boleh direkodkan dalam log pula", idea itu tidak salah, tetapi orang yang sebenarnya telah menangani mesej ralat dalam log besar akan faham. Adalah jelas bahawa ia boleh dikendalikan secara seragam, tetapi ia tidak dilakukan. Ini dianggap sebagai kecacatan atau kesilapan reka bentuk. Bukan penyelesaian yang paling berkesan untuk masalah

Saya orang awam, sila klik ringan^

Gunakan Spring AOP untuk mengendalikan pengecualian secara seragam Sudah tentu, kaedah ketiga adalah lebih baik. Gunakan Spring AOP untuk memintas pengecualian yang dilemparkan oleh lapisan perkhidmatan, merekodkan semua log pengecualian yang tidak dikendalikan dan menukar semua pengecualian yang tidak dikendalikan kepada pengecualian sistem tersuai bersatu supaya lapisan pengawal atau lapisan Rpc boleh mengendalikan pengecualian tersuai ini Maklumat disalurkan kembali ke bahagian hadapan. dan dipaparkan pada bahagian pelayar.
Jangan lupa, fungsi sebenar menggunakan Spring AOP untuk memintas pengecualian adalah untuk memisahkan logik pemprosesan pengecualian daripada logik pemprosesan biasa. Jadi pada tahap manakah yang anda fikir butiran pengecualian dikawal? Ini berdasarkan logik perniagaan anda. Sebagai contoh, operasi menambah, memadam, mengubah suai dan menyemak pangkalan data gagal? Gagal memanggil antara muka luaran? Maklumat abnormal lain, dsb.
Kaedah syarikat anda adalah tidak teratur dan tidak sesuai. Semasa memproses log, anda perlu memasukkan beberapa kod pemprosesan dalam setiap blok cuba-tangkap Kadangkala kod pengendalian pengecualian adalah lebih daripada kod pelaksanaan biasa, mencemarkan kod pelaksanaan biasa. Kod pengendalian pengecualian bertaburan dan sangat menyusahkan untuk diubah suai. Sesetengah pengecualian tidak boleh dikendalikan dan diubah suai secara seragam.
Jika penamaan kaedah perniagaan dalam Perkhidmatan tidak dinamakan mengikut peraturan yang telah ditetapkan, AOP tidak boleh memintasnya. Dengan kata lain, kawalan transaksi tidak boleh dimuatkan. Konvensyen penamaan ini perlu dinyatakan dalam fail konfigurasi.

Kami semua mengendalikan pengecualian aop dalam lapisan pengawal
Pengecualian dibahagikan kepada pengecualian bukan ajax dan pengecualian ajax Kerana kami menggunakan jquery, bahagian hadapan dan bahagian belakang tidak dipisahkan sepenuhnya dipaparkan secara langsung oleh bahagian belakang

1. pengecualian ajax: Mengandungi X-Requested-With dalam pengepala untuk menentukan

2. Pengecualian bukan ajax:
   selain pengecualian ajax Cara meja depan anda memaparkan ralat kepada pelanggan pastinya berbeza, jadi kendalikannya secara berasingan dalam Interceptor (penapis) (aop)

Dalam setiap kaedah kelas perkhidmatan, tidak dikatakan bahawa keseluruhan kaedah dibalut dengan tangkapan cuba Itu terlalu banyak Pengecualian dibahagikan kepada perkara yang tidak dapat anda kawal, seperti pengecualian pangkalan data, penunjuk nol, dll. Ini tidak perlu ditangkap. Dalam perkhidmatan Ia dilemparkan berdasarkan perniagaan yang tidak normal dalam perniagaan Contohnya, jika nama pengguna diulang, saya akan membuang BizException ("Nama pengguna pendua"), di mana BizException mewarisi RuntimeException<.>

Adakah anda menggunakan spring mvc? Spring MVC mempunyai pengendalian pengecualian global Anda boleh mencarinya Saya tidak dapat menyatakan butirannya dengan mudah pada telefon bimbit saya.