Saya telah belajar MVC selama dua tahun, tetapi beberapa konsep masih kabur, saya harap saya dapat mencari jawapannya di sini.
Saya pernah melihat seseorang mengatakan bahawa Pengawal tidak bertanggungjawab untuk pemprosesan data, dan semuanya dikendalikan oleh Perkhidmatan kami Apa sahaja jenis data yang dikembalikan dari hujung hadapan halaman web, jenis data dimajukan terus ke Perkhidmatan, dan maka Perkhidmatan mengendalikannya; tetapi terdapat satu lagi suara yang mengatakan bahawa kadangkala berbilang Perkhidmatan dipanggil pada masa yang sama Jika objek dirangkumkan dalam Pengawal, ia akan dielakkan beberapa kali dalam kaedah Perkhidmatan.
Soalan lain ialah tentang interaksi antara Pengawal dan Perkhidmatan.
Untuk memastikan interaksi pelanggan yang baik di bahagian hadapan, kami sering mengembalikan beberapa gesaan ralat ke bahagian hadapan melalui Pengawal, seperti nama pengguna sudah wujud, nama pengguna dan kata laluan tidak sepadan, dsb. Walau bagaimanapun, kami memproses logik perniagaan dalam lapisan Perkhidmatan Jika kami menetapkan nilai pulangan kaedah log masuk (Nama pengguna rentetan, kata laluan rentetan) kepada boolean, kami tidak boleh mengembalikan berbilang ralat tetapkan beberapa tetapan asas.
"Idea mewah" saya sendiri ialah saya membuang beberapa RuntimeExceptions tersuai dalam Perkhidmatan, dan kemudian menggunakan TryCatch dalam Pengawal untuk mengendalikan ralat yang berbeza, tetapi saya fikir cara melontar pengecualian ini tidak sesuai. Saya keliru baru-baru ini dan akan mula mengerjakan projek saya yang seterusnya. Saya harap anda boleh membantu saya menyelesaikan kekeliruan saya.
Terima kasih.
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Projek kami dibahagikan kepada tiga peringkat:
Lapisan persembahan: Spring MVC, bertanggungjawab untuk menerima permintaan Http, memaparkan (mengembalikan) hasil dan pengesahan mudah
Lapisan apl: Menyediakan fungsi lapisan aplikasi, seperti import, eksport dan pengesahan kompleks
Lapisan domain: mengendalikan logik perniagaan, seperti beberapa Perkhidmatan
Jujukan panggilan adalah tunggal: Controller->App->Domain
Dan perhubungan persepsi ialah: Controller->App->Domain, iaitu, lapisan bawah tidak melihat lapisan atas
Izinkan saya menjawab soalan pertama anda dahulu:
Bolehkah saya memahami soalan pertama yang anda nyatakan bermaksud bahawa parameter yang diterima oleh permintaan Http bukanlah Objek, tetapi sekumpulan jenis asas, tetapi parameter yang diterima oleh Perkhidmatan anda ialah Objek. Pendekatan yang betul adalah untuk menukar parameter "mentah" menjadi objek Objek dalam Pengawal, dan kemudian memanggil Perkhidmatan.
Kenapa ini betul? Oleh kerana Perkhidmatan tergolong dalam lapisan Domain, yang mengandungi logik perniagaan, parameter yang diterima hendaklah direka bentuk mengikut keperluan anda sendiri. Anda tidak seharusnya mempertimbangkan parameter daripada lapisan Web, supaya ia boleh digunakan semula dalam senario yang berbeza.
Sebagai contoh, Perkhidmatan anda harus boleh diguna semula dalam persekitaran lapisan pembentangan yang berbeza:
Dalam program web, parameter yang dilalui oleh pengguna diberikan kepada anda dalam bentuk POST/GET
Dalam program perkhidmatan Web, parameter yang dilalui oleh pengguna ialah json atau SOAP
Dalam program Swing, parameter yang dilalui oleh pengguna ialah rentetan
Jika anda mengikat Perkhidmatan pada persekitaran lapisan pembentangan tertentu, maka parameter kaedahnya pasti akan menjadi tidak stabil, mengakibatkan ketidakupayaan untuk menggunakan semula.
Begitu juga, nilai pulangan Perkhidmatan tidak seharusnya terikat pada senario tertentu.
Pada peringkat Spring MVC, Pengawal boleh menukar parameter dengan mudah kepada Objek, dokumen berkaitan
Soalan kedua:
Soalan ini boleh dibahagikan kepada tiga bahagian:
1) Di mana untuk melakukan pengesahan mudah seperti had panjang parameter, penghakiman tidak kosong, dsb.?
Pengesahan mudah dilakukan menggunakan mekanisme yang disediakan oleh Spring MVC sendiri, dokumen berkaitan, dokumen berkaitan
2) Di manakah pengesahan dilakukan selari dengan logik perniagaan Perkhidmatan itu sendiri, seperti menentukan sama ada akaun pengguna dilumpuhkan semasa membuat pesanan?
Saya cenderung melakukan semakan logik ini pada lapisan Aplikasi Pengawal memanggil Apl, dan Apl memanggil dua Perkhidmatan berbeza untuk menyatukan perniagaan
3) Bagaimana untuk mengesahkan logik perniagaan yang berkaitan dengan Perkhidmatan itu sendiri
Anda memberikan contoh log masuk. Tiada masalah untuk menggunakan pengecualian untuk memaklumkan pemanggil (Pengawal) hasil pemprosesan. Anda juga boleh memperkayakan nilai pulangan Perkhidmatan untuk mencapai matlamat ini, tetapi perlu diperhatikan bahawa reka bentuk nilai pulangan Perkhidmatan tidak boleh terikat pada persekitaran lapisan pembentangan, jika tidak, ia tidak boleh digunakan semula Inilah sebabnya @YaTou menyebut apache-shiro Mekanisme pengecualian digunakan untuk mengendalikan kegagalan pengesahan, kerana ini sahaja yang cukup umum.Saya fikir adalah betul bahawaPerkhidmatan , maka Perkhidmatan ini boleh digunakan semula.
Controlertidak bertanggungjawab untuk memproses data, keranaControllertidak boleh digunakan semula dalamspring-mvc, tetapi jika anda The logik perniagaan disarikan kepadaController不负责处理数据是正确的, 因为在spring-mvc中Controller是不能复用的, 但是如果你把业务逻辑抽象成Service, 那么这个Service就是可以复用的.至于你说的 "在Controller就将对象封装好了，就免于在Service的方法中多次封装" , 没太明白什么意思, 你每个
Service需要什么参数,Controller就给什么参数, 至于需要的参数是否需要封装成对象就可以自己权衡了.你所说的
Mengenai apa yang anda katakan "merangkumkan objek dalam Pengawal, anda tidak perlu merangkumnya beberapa kali dalam kaedah Perkhidmatan", saya tidak begitu faham apa yang anda maksudkan. Apakah parameter yang anda perlukan untuk setiaplogin(String username,String password), 你想抽象成Service用异常处理处理多种不同的结果, 这个我觉得完全没有问题, 而且我觉得非常好啊, 很多认证框架都用的这种方式, 至少我看的apache-shiroapache-shiromenggunakan pengecualian untuk menangani situasi kegagalan pengesahan yang berbeza.Tiada jawapan standard untuk soalan pertama Adalah lebih baik untuk menganalisis situasi tertentu dan membuat lapisan logik jelas dan mudah untuk dikekalkan.
Bagi soalan kedua, interaksi yang anda berikan di sini tertakluk kepada kawalan kebenaran Secara amnya, penapis, aop, proksi, refleksi, dll. boleh digunakan untuk mencapai penutupan kod juga dilemparkan sekali dalam kod kawalan terpusat ini baik, tetapi saya merasa sukar untuk mengeraskannya secara langsung dalam Pengawal. Lapisan Perkhidmatan lebih kepada memanggil kaedah lapisan Dao untuk melaksanakan beberapa pemprosesan logik perniagaan yang kompleks yang melibatkan berbilang jadual juga diletakkan pada lapisan ini (sudah tentu rangka kerja telah melakukan semua ini sekarang), jadi lapisan Perkhidmatan Lapisan secara amnya tidak. pengecualian buang (pengesahan parameter dilakukan dalam Pengawal dan lapisan sebelumnya, jadi tiada pengecualian berkaitan perniagaan berlaku dan Dao menyekat pengecualian asas yang berkaitan dengan pangkalan data).
Sudah tentu, ini adalah pendapat peribadi, tidak ada formula tetap, seperti yang saya katakan, bagus jika lapisannya jelas dan mudah dijaga.
1. Pengawal adalah tunggal secara lalai, tetapi ia boleh digantikan dengan @Scope(value = "prototype")
2. Log masuk boleh return int, tambah enumeration sendiri
3. Ditetapkan bahawa logik diproses dalam lapisan Perkhidmatan Ia adalah lebih baik untuk mempunyai lebihan kod dan mengoptimumkannya
Semua orang akan mempunyai pendapat yang berbeza Apa yang lebih penting untuk pembangunan adalah pengoptimuman dan pengurangan redundansi, daripada apa yang mesti dilakukan. . .1. Kembalikan nilai, buat pertimbangan pada lapisan Pengawal, dan buang pengecualian sepadan yang anda inginkan.
Sudah tentu, ini hanya pendekatan semasa kami, sila kongsikan. . .
Anda boleh membaca artikel saya
AOP, MVC - Pembelajaran musim bunga dan refleksi pada CodeIgniter /a/11...
Adalah disyorkan bahawa logik diletakkan dalam perkhidmatan Kami sedang mengusahakan seni bina perkhidmatan mikro yang diedarkan. Kami biasa meletakkannya pada lapisan pengawal yang perlu digunakan apl tidak boleh dikongsi jika ia diletakkan pada Bar.
Sama ada objek yang dikapsulkan berada dalam Pengawal atau Perkhidmatan bergantung pada situasi tertentu, saya secara peribadi berpendapat bahawa jika ia adalah parameter yang mudah, ia adalah wajar untuk merangkumnya dalam Pengawal Jika ia diletakkan dalam Perkhidmatan, ia akan kelihatan sangat berlebihan dan membawa kepada kemerosotan Servis; untuk soalan kedua, tidak dibenarkan menggunakan penghitungan atau kod status yang berbeza untuk membuat pertimbangan terhadap Pengawal dan mentakrifkan sepenuhnya satu set mekanisme pengendalian pengecualian sendiri dan buangnya terus pada lapisan Perkhidmatan Projek ini telah menyasarkan mekanisme pengendalian pengecualian seperti perniagaan ini yang secara langsung mengembalikan mesej ralat Perkhidmatan dan kod ralat ke lapisan Lihat, membenarkan pelanggan mengendalikannya berdasarkan kod status dan. mesej ralat