Contoh untuk menerangkan maksud dan pembahagian tanggungjawab seni bina MVC

Baru-baru ini saya bertanggungjawab untuk projek menggunakan rangka kerja MVC Rangka Kerja Yii Pada mulanya saya fikir struktur itu sangat teguh.

Tetapi apabila saya mendalami pemahaman saya tentang logik perniagaan, saya mula menyedari betapa seriusnya masalah itu.

Saya salah faham Pengawal dalam MVC, dan mengambil mudah berdasarkan pengalaman lalu bahawa saya meletakkan semua logik perniagaan dalam pencapaian Pengawal. action

Akibatnya, setiap

Pengawal mempunyai beribu-ribu baris kod , yang semakin kembung .

Akhirnya, saya membuat keputusan untuk memfaktorkan semula kod itu ialah keperluan untuk antara muka API terbuka.

Mengikut seni bina semasa, kod itu pada asasnya mustahil untuk digunakan semula saya perlu menulis banyak fungsi berulang kali, yang benar-benar tidak boleh diterima.

Pengaturcaraan berorientasikan objek bukan sekadar istilah dalam buku teks!

Hanya apabila saya mula berlatih barulah saya menyedari betapa jarangnya mempunyai kesedaran berorientasikan objek dan perspektif global.

1 Apakah sebenarnya MVC

Model-View-Controller (MVC) ialah sejenis

Rangka kerja reka bentuk (corak reka bentuk) .

Matlamat MVC adalah untuk memisahkan logik perniagaan daripada pertimbangan antara muka pengguna.

Dengan cara ini, pembangun boleh menukar setiap bahagian dengan lebih mudah tanpa menjejaskan bahagian yang lain.

Dalam MVC,

Model mewakili
• peraturan data dan perniagaan; >Elemen antara muka pengguna, seperti teks, borang
, dll.;
• Pengawal mengurus komunikasi
antara model dan pandangan.
• MVC dilaksanakan dalam pelbagai bahasa pengaturcaraan Sebagai contoh, dalam pembangunan aplikasi J2EE, View boleh dilaksanakan oleh jsp Controller ialah servlet, kini umumnya dilaksanakan dengan Model Struts; Ia dilaksanakan oleh entiti Bean.

2 Apakah masalah yang saya hadapi

Yii Framework ialah rangka kerja PHP popular yang meminjam konsep

() daripada Ruby on Rails.

Setiap

dalam pangkalan data boleh menggunakan kelas ActiveRecord untuk melakukan operasi penambahan, pemadaman, pengubahsuaian dan pertanyaan dengan mudah. AR

Ia menganggap AR sebagai Model dan mengesyorkan meletakkannya di bawah direktori bernama

. tableARJadi, selepas saya menjana AR secara automatik yang sepadan dengan jadual, saya mengambil mudah bahawa saya sudah mempunyai lapisan Model.

Sebenarnya, models

AR hanyalah DAO (lapisan akses data), bukan lapisan Model

.

Hampir semua perniagaan kami diletakkan dalam Pengawal: Buat pelbagai pertimbangan logik pada borang yang diserahkan oleh pengguna, lakukan pengiraan, sertakan AR untuk menyimpan data...

Oleh kerana akan terdapat berbilang

dalam Pengawal, setiap mempunyai pemprosesan perniagaan sedemikian.

Akhir sekali, saya mendapati bahawa kod Pengawal saya telah melebihi 1000 baris.

actionTiba-tiba pada suatu hari, ketua berkata bahawa sistem kami harus membuka API untuk sistem lama sedia ada untuk memanggil dan menyediakan antara muka pihak ketiga. action

Pihak ketiga hanya perlu memberikan parameter, dan sistem ini hanya memberikan nilai hasil. Ia tidak mengambil berat tentang pemprosesan perniagaan.

Perkara buruknya ialah Pengawal telah melaksanakan perkhidmatan tersebut, tetapi ia menerima penyerahan borang. Bagaimanakah ia juga boleh menerima dokumen SOAP xml?

Pengawal, seperti kondom, hendaklah nipis yang mungkin.

Tanggungjawabnya seharusnya hanya menerima input pengguna dan kemudian segera memajukannya ke kelas lain untuk diproses

.

Dengan cara ini, Pengawal hanya bertanggungjawab untuk menyediakan antara muka yang berbeza, supaya kami boleh memisahkan logik perniagaan dan perniagaan yang dipisahkan boleh digunakan semula dengan mudah. Siapa yang akan mengendalikan bahagian perniagaan yang berasingan ini? Jawapannya sepatutnya Model

.

3 Tanggungjawab View

View bahagian agak jelas, ia bertanggungjawab untuk paparan.

Apa-apa sahaja yang tiada kaitan dengan antara muka paparan tidak seharusnya muncul dalam paparan.

Oleh itu, secara amnya tidak sepatutnya mempunyai penyata penghakiman yang kompleks atau proses pengiraan yang rumit dalam Lihat

.

boleh mempunyai pernyataan gelung mudah dan pernyataan pemformatan. Sebagai contoh, senarai teks pada halaman utama blog adalah sejenis gelung. Untuk aplikasi web PHP,

HTML ialah kandungan utama dalam View

.

Paparan tidak boleh memanggil kaedah penulisan Model

.

Dalam erti kata lain, View hanya membaca data daripada Model tetapi tidak menulis semula Model.

Jadi kami katakan bahawa View dan Model tidak dapat dipisahkan.

Selain itu, $_GET dan $_POST tidak diakses secara langsung dalam View dan harus dihantar ke View by Controller.

Selain itu, View umumnya tidak mempunyai sebarang kandungan untuk menyediakan pemprosesan data , seperti menanyakan pangkalan data, dsb.

Ini biasanya diletakkan dalam Pengawal dan dihantar ke paparan dalam bentuk pembolehubah.

Dalam erti kata lain, data yang akan digunakan dalam paparan ialah pembolehubah .

4 Tanggungjawab Model

Untuk Model, perkara paling penting ialah menyimpan dan mengeluarkan maklumat .

Sebagai contoh, kelas Post mesti mempunyai atribut title untuk menyimpan tajuk siaran blog dan mesti ada operasi pemadaman Ini semua kandungan Model.

Data, tingkah laku dan kaedah ialah kandungan utama Model .

Dalam kerja sebenar, Model mempunyai jumlah kod terbesar dalam MVC .

Model ialah bahagian logik yang paling kompleks, kerana logik perniagaan aplikasi juga mesti dinyatakan di sini.

Beri perhatian kepada membezakan Model daripada Pengawal.

Model mengendalikan logik perniagaan dan Pengawal hanya menyelaraskan hubungan antara Model dan View.

Selagi ia berkaitan dengan perniagaan, ia harus diletakkan dalam Model.

Pengesahan data, awampemalar dan pembolehubah semuanya harus diletakkan dalam lapisan model,

Dengan kata lain, atribut atau kaedah yang boleh digunakan semula harus diletakkan dalam lapisan model, ditakrifkan sekali dan digunakan di mana-mana sahaja.

Model tidak boleh mengakses permintaan, sesi dan data persekitaran lain, ini harus disuntik oleh Pengawal.

Reka bentuk yang baik mestilah Model gemuk dan Pengawal nipis.

5 Tanggungjawab Pengawal

Untuk Pengawal, ia adalah terutamanya untuk membalas permintaan pengguna dan memutuskan pandangan untuk gunakan, yang perlu disediakan Data apa yang digunakan untuk memaparkan .

Oleh itu, untuk kod akses request hendaklah diletakkan dalam Pengawal , seperti $_GET, $_POST, dsb.

Pengawal harus dihadkan untuk mendapatkan data permintaan pengguna, tidak boleh melakukan sebarang operasi atau prapemprosesan pada data , ini harus diletakkan di dalam Model.

Untuk operasi penulisan data, perlu memanggil kaedah kelas Model untuk diselesaikan.

Sebagai tindak balas kepada permintaan pengguna, paparan paparan dipanggil.

Selain itu, secara amnya tidak sepatutnya ada kod HTML atau perkara lapisan pembentangan lain , ini sepatutnya menjadi kandungan Paparan.

6 Pencerahan

Terdapat perenggan ini dalam dokumentasi rasmi Rangka Kerja Yii:

Dalam aplikasi MVC yang direka dengan baik, pengawal selalunya sangat nipis, mungkin mengandungi hanya beberapa dozen baris kod manakala model sangat gemuk, mengandungi kebanyakan kod yang bertanggungjawab untuk mewakili dan memanipulasi data.

Ringkasnya, Kaya Model adalah Lebih Baik.

Atas ialah kandungan terperinci Contoh untuk menerangkan maksud dan pembahagian tanggungjawab seni bina MVC. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!