MVC standard melaksanakan logik perniagaan secara langsung dalam pengawal, tetapi dalam projek sebenar, masih disyorkan untuk merangkum lapisan perkhidmatan antara pengawal dan operasi pangkalan data. Di satu pihak, pengawal bertindak balas kepada URL permintaan yang berbeza, jadi akan terdapat banyak duplikasi dalam kefungsian; Sebaliknya, anda mesti menganggap bahawa fungsi perkhidmatan anda mungkin terdedah kepada bahagian hadapan lain pada masa hadapan, seperti input aplikasi lain, atau terminal yang berbeza (seperti APP, mudah alih H5, dll.);
Sangat teruk, sangat sukar untuk dikembangkan dan kebolehselenggaraan juga sangat lemah.
Pengawal haruslah lapisan nipis, dan logik perniagaan harus diletakkan dalam lapisan perkhidmatan untuk diproses sebanyak mungkin Ia juga harus lebih bebas dari segi butiran perkhidmatan dan penggunaan perkhidmatan.
Sudah tentu ia tidak bagus Lapisan pengawal hanya bertanggungjawab untuk interaksi data perniagaan, dan logik perniagaan dikendalikan oleh lapisan perkhidmatan
Lapisan Pengawal projek yang saya ambil alih sekarang juga sangat besar Satu kaedah mempunyai ratusan baris, dan terdapat berbilang lapisan jika bersarang penyelenggaraan kemudian. Anda perlu memahami logik perniagaan sebelumnya. Saya secara peribadi merasakan bahawa kaedah yang lebih baik adalah pengawal-perkhidmatan-dao, dengan perkhidmatan yang bertanggungjawab untuk operasi logik tertentu dan dipisahkan daripada satu sama lain mungkin;
Walaupun diletakkan dalam perkhidmatan, ia akan menjadi kucar-kacir. . Masih memerlukan kaedah lain untuk mengelakkan situasi perniagaan yang rumit dan kebolehselenggaraan kod yang lemah
Biar rakan sekerja melihat kod hari ini Perkara pertama yang dia katakan ialah anda harus meletakkan kod pengawal dalam perkhidmatan;=_=; Ia bergantung terutamanya pada kerumitan perniagaan perniagaan yang sangat mudah, maka tidak perlu dari pengawal kepada perkhidmatan kepada dao juga bergantung pada spesifikasi pembangunan seluruh pasukan;
MVC standard melaksanakan logik perniagaan secara langsung dalam pengawal, tetapi dalam projek sebenar, masih disyorkan untuk merangkum lapisan perkhidmatan antara pengawal dan operasi pangkalan data.
Di satu pihak, pengawal bertindak balas kepada URL permintaan yang berbeza, jadi akan terdapat banyak duplikasi dalam kefungsian;
Sebaliknya, anda mesti menganggap bahawa fungsi perkhidmatan anda mungkin terdedah kepada bahagian hadapan lain pada masa hadapan, seperti input aplikasi lain, atau terminal yang berbeza (seperti APP, mudah alih H5, dll.);
Sangat teruk, sangat sukar untuk dikembangkan dan kebolehselenggaraan juga sangat lemah.
Pengawal haruslah lapisan nipis, dan logik perniagaan harus diletakkan dalam lapisan perkhidmatan untuk diproses sebanyak mungkin Ia juga harus lebih bebas dari segi butiran perkhidmatan dan penggunaan perkhidmatan.
Sudah tentu ia tidak bagus Lapisan pengawal hanya bertanggungjawab untuk interaksi data perniagaan, dan logik perniagaan dikendalikan oleh lapisan perkhidmatan
Lapisan Pengawal projek yang saya ambil alih sekarang juga sangat besar Satu kaedah mempunyai ratusan baris, dan terdapat berbilang lapisan jika bersarang penyelenggaraan kemudian. Anda perlu memahami logik perniagaan sebelumnya. Saya secara peribadi merasakan bahawa kaedah yang lebih baik adalah pengawal-perkhidmatan-dao, dengan perkhidmatan yang bertanggungjawab untuk operasi logik tertentu dan dipisahkan daripada satu sama lain mungkin;
Walaupun diletakkan dalam perkhidmatan, ia akan menjadi kucar-kacir. . Masih memerlukan kaedah lain untuk mengelakkan situasi perniagaan yang rumit dan kebolehselenggaraan kod yang lemah
Biar rakan sekerja melihat kod hari ini Perkara pertama yang dia katakan ialah anda harus meletakkan kod pengawal dalam perkhidmatan;=_=;
Ia bergantung terutamanya pada kerumitan perniagaan perniagaan yang sangat mudah, maka tidak perlu dari pengawal kepada perkhidmatan kepada dao juga bergantung pada spesifikasi pembangunan seluruh pasukan;