Memandangkan pembangunan bahagian hadapan semakin dihargai dan perkadaran kod pelanggan semakin meningkat dari hari ke hari, persoalan tentang cara menggunakan corak MVC dalam pembangunan JavaScript nampaknya disebut sepanjang masa, jadi saya ingin bercakap secara ringkas tentang pandangan saya di sini.
Idea asas corak MVC adalah untuk mengurangkan gandingan dan memudahkan pembangunan dengan merangkum aplikasi kepada tiga bahagian: model, paparan dan pengawal. Sukar untuk mengatakan ini. Mari kita lihat contoh:
<select id="selAnimal"> <option value="cat">cat</option> <option value="fish">fish</option> <option value="bird">bird</option> </select> <p id="whatDoesThisAnimalDo"></p> <script type="text/javascript"> document.getElementById('selAnimal').onchange = function() { var thisAnimalDoes; switch ( this.value ) { case 'cat': thisAnimalDoes = "cat meows"; break; case 'fish': thisAnimalDoes = "fish swims"; break; case 'bird': thisAnimalDoes = "bird flies"; break; default: thisAnimalDoes = "wuff?"; } document.getElementById('whatDoesThisAnimalDo').innerHTML = thisAnimalDoes; } </script>
Program kecil ini akan menggemakan perkara yang boleh dilakukan oleh haiwan yang anda pilih daripada menu lungsur "selAnimal" ke halaman web. Di atas adalah kod yang ditulis tanpa menggunakan sebarang corak reka bentuk atau idea pengaturcaraan. Jika kita ingin menggunakan corak MVC di sini, apakah rupa kod tersebut?
<select id="selAnimal"> <option value="cat">cat</option> <option value="fish">fish</option> <option value="bird">bird</option> </select> <p id="whatDoesThisAnimalDo"></p> <script type="text/javascript"> // whatDoesAnimalDo 就是一个controller var whatDoesAnimalDo = { // 选择视图 start: function() { this.view.start(); }, // 将用户的操作映射到模型的更新上 set: function(animalName) { this.model.setAnimal(animalName); }, }; // whatDoesAnimalDo的数据model whatDoesAnimalDo.model = { // animal的数据 animalDictionary: { cat: "meows", fish: "swims", bird: "flies" }, // 当前的animal,也就是这个application的状态 currentAnimal: null, // 数据模型负责业务逻辑和数据存储 setAnimal: function(animalName) { this.currentAnimal = this.animalDictionary[animalName] ? animalName : null; this.onchange(); }, // 并且通知视图更新显示 onchange: function() { whatDoesAnimalDo.view.update(); }, // 还需要响应视图对当前状态的查询 getAnimalAction: function() { return this.currentAnimal ? this.currentAnimal + " " + this.animalDictionary[this.currentAnimal] : "wuff?"; } }; // whatDoesAnimalDo的视图 whatDoesAnimalDo.view = { // 用户输入触发onchange事件 start: function() { document.getElementById('selAnimal').onchange = this.onchange; }, // 该事件将用户请求发送给控制器 onchange: function() { whatDoesAnimalDo.set(document.getElementById('selAnimal').value); }, // 视图更新显示的方法,其中视图会向model查询当前的状态,并将其显示给用户 update: function() { document.getElementById('whatDoesThisAnimalDo').innerHTML = whatDoesAnimalDo.model.getAnimalAction(); } }; whatDoesAnimalDo.start(); </script>
...Tiba-tiba kod tersebut menjadi sangat berlebihan....
——Odu belum melaksanakan mod pemerhati di dalamnya lagi...
Ia benar-benar tidak baik.
Ini mengeluarkan kritikan terbesar terhadap corak MVC: menggunakan corak MVC dalam sistem yang mudah akan meningkatkan kerumitan struktur dan mengurangkan kecekapan.
Jadi, saya berpendapat bahawa kecuali beberapa kawalan javascript, seperti klik-mana-mana-untuk-edit datagrid/kawalan pokok, atau editor teks kaya seperti FckEditor/tinyMCE yang menyokong pemalam tersuai, yang sangat sesuai untuk menggunakan MVC, dalam kebanyakan Dalam sistem B/S yang praktikal, selagi anda mengikut corak kilang dalam pembangunan JavaScript, anda akan mendapat banyak manfaat. Ini disebabkan oleh sifat pembangunan bahagian hadapan dan pembangunan bahagian belakang yang berbeza. Jika anda menggunakan corak MVC dalam projek ASP.net atau JSP, SDK akan lebih kurang menjana beberapa paparan dan kod pengawal secara automatik. Tetapi bagaimana pula dengan JavaScript - JavaScript tidak mempunyai SDK yang berguna Walaupun terdapat banyak rangka kerja yang matang, ia akhirnya akan meningkatkan jumlah pembangunan.
Berbanding dengan jumlah pembangunan, apa yang lebih menyusahkan ialah isu kecekapan. Interkomunikasi antara tiga lapisan adalah overhed tambahan. Untuk bahagian pelayan, overhed yang disebabkan oleh komunikasi ini hampir boleh diabaikan. Tetapi untuk bahasa yang agak tidak cekap seperti javascript, beberapa lagi panggilan dan mendengar acara jelas akan mengurangkan prestasi. Lebih-lebih lagi, kerana ciri penutupan javascript, kebocoran memori mungkin berlaku secara tidak sengaja Ini adalah kes sahih mencuri ayam tetapi kehilangan beras...
Oleh itu, untuk pembangunan JavaScript, pembangunan sederhana mungkin lebih penting daripada menggunakan pengetahuan akademik yang telah anda pelajari Lagipun, pembangunan front-end adalah berdasarkan penyelesaian masalah praktikal, bukan untuk menunjukkan kemahiran. Sudah tentu, Dflying gg mempunyai pepatah bahawa "pemfaktoran semula ada di mana-mana" - jika anda merasakan kod anda sendiri semakin kucar-kacir dan lebih sukar untuk dikekalkan, maka anda harus mempertimbangkan sama ada anda perlu menggunakan MVC untuk memfaktorkannya semula~
Satu lagi perkara: Adakah keseluruhan pembangunan bahagian hadapan tidak perlu lagi menggunakan MVC? tidak tidak~ Malah, keseluruhan pembangunan bahagian hadapan ialah seni bina MVC yang besar——
Model: Maklumat dalam HTML/XHTML
Lihat: Helaian gaya
Pengawal: Skrip EMA dan skrip lain
Bukankah ini matlamat utama standard web....
Oleh itu, sentiasa lebih penting untuk memahami struktur keseluruhan kod bahagian hadapan berbanding aplikasi berlebihan model reka bentuk dalam pembangunan JavaScript!
Walau bagaimanapun, terdapat juga beberapa rangka kerja MVC yang sangat baik Gordon L. Hempton, penggodam dan pereka bentuk di Seattle, membuat perbandingan di sini untuk melihat:
1. Backbone.js - Kelebihan: komuniti yang kuat, momentum yang kuat;
2. SproutCore - Kelebihan: sokongan untuk mengikat, komuniti yang boleh dipercayai, bilangan ciri yang besar;
3. Sammy.js - Kelebihan: mudah dipelajari dan lebih mudah untuk disepadukan dengan aplikasi pelayan sedia ada: terlalu mudah untuk digunakan dalam aplikasi besar.
4. Spine.js - Kelebihan: ringan, dokumentasi lengkap; Kelemahan: Konsep terasnya "tulang belakang" ialah antara muka pengguna tak segerak, yang bermaksud bahawa antara muka pengguna tidak akan disekat dan asas ini cacat. .
5. Cappuccino - Kelebihan: Rangka kerja besar yang difikirkan dengan baik, komuniti yang baik, model warisan yang hebat: Dicipta oleh pembangun iOS, menggunakan JavaScript untuk mensimulasikan Objektif-C.
6. Knockout.js - Kelebihan: Sokongan untuk pengikatan, dokumentasi dan tutorial yang lengkap;
7. Javascript MVC - Kelebihan: komuniti yang boleh dipercayai; Kelemahan: model pewarisan berasaskan rentetan yang lemah, hubungan yang terlalu rapat antara pengawal dan pandangan serta kekurangan pengikatan.
8. GWT (Google Web Toolkit) - Kelebihan: rangka kerja komprehensif, komuniti yang baik, model pewarisan komponen berasaskan Java yang boleh dipercayai Abstraksi di atas agak kekok.
9. Penutupan Google——Kelebihan: Sistem komposisi UI berasaskan komponen yang sangat baik. Kelemahan: Kekurangan sokongan mengikat UI.
10. Ember.js - Kelebihan: Sistem templat yang sangat kaya, dengan paparan komposit dan pengikatan UI: Ia agak baharu dan dokumentasi tidak cukup lengkap.
11. Angular.js - Kelebihan: Ia mempunyai pertimbangan yang baik untuk skop templat dan reka bentuk pengawal, mempunyai sistem suntikan pergantungan dan menyokong sintaks pengikatan UI yang kaya. Kelemahan: Modulariti kod tidak kuat, dan modulariti pandangan tidak mencukupi.
12. Batman.js——Kelebihan: kod yang jelas, kaedah pengikatan mudah dan kegigihan: pengawal tunggal digunakan.