Sebagai contoh, jika anda menulis Senarai Todo, ikut MVC bahagian hadapan dan tulisnya seperti ini:

• Model: Tatasusunan JSON, sepadan dengan kandungan dalam pangkalan data, iaitu teks, status penyiapan
• Lihat: templat HTML atau templat DOM, iaitu antara muka
• Pengawal: Pengguna beroperasi pada antara muka dan kemudian menukar Model

Secara amnya terdapat hubungan sedemikian (tidak begitu tepat, dan pelbagai pelaksanaan MVC tidak konsisten sepenuhnya):

• Seluruh program dikemas kini sekitar perubahan Model
• Paparan dipaparkan mengikut Model dan dikemas kini semasa Model dikemas kini
• Pengawal menerima pencetus peristiwa dalam Lihat dan mengubah suai Model

Ia adalah satu kitaran secara keseluruhan~ Bermula dari Model, menambah operasi pengguna di tengah, dan kemudian kembali ke Model
Ini adalah idea untuk menulis grafik, iaitu memisahkan data daripada antara muka dan memudahkan atur cara.
Dengan kata lain, abstrakkan data minimum yang mewakili antara muka sebagai Model dan operasi minimum sebagai Pengawal.
View berubah dengan Model, malah boleh ditukar sesuka hati mengikut keperluan pengguna.

secara kasar:

atau:

Jawapan berikut adalah pendapat peribadi, sila betulkan saya jika saya salah.

Mari kita bercakap tentang PHP asli dahulu.
Pemprosesan data, halaman dipaparkan bersama-sama, bersarang antara satu sama lain.

MVC berbeza, pemprosesan data dan paparan diasingkan.
Apabila perniagaan tidak rumit, anda pada dasarnya boleh mengendalikannya dengan V dan C.
Abang C memproses data, membungkusnya dan menyerahkannya kepada V. Beritahu V dengan sungguh-sungguh: "Abang V, semua data ada di sini, ambil dan paparkan!"
V berkata: "Baiklah Abang C dan kemudian memaparkan data di bahagian hadapan. Brother V juga mempunyai sintaks yang serupa dengan foreach, yang digunakan untuk memaparkan data yang diberikan oleh Brother C.

Kadang-kadang perniagaan menjadi rumit dan Abang C sedikit penat memproses data seorang diri, jadi Abang C memanggil Abang M untuk membantu.
Abang M membantu Abang C melakukan kerja yang berulang-ulang dan memberikannya kepada Abang C selepas mengendalikannya. Kemudian Abang C akan menyerahkannya kepada Abang V.

PHP asli adalah seperti penyumberan luar, selalunya seseorang perlu mengendalikan perkara hadapan dan belakang.
MVC adalah seperti sebuah syarikat yang matang, dengan bahagian hadapan dan hujung belakang. Pembahagian kerja adalah jelas.

Semua orang telah bercakap tentang konsep sebenarnya, makna MVC telah berubah secara halus. Terdapat perbezaan besar antara MVC asal perisian CS dan MVC php ruby ​​​​python. Malah mungkin konsep itu telah lama menjadi MVP, tetapi semua orang sudah biasa dengan MVC dan telah salah faham

Saya fikir dari segi projek sebenar, anda boleh memahami secara kasar intipati dan matlamat MVC dengan melakukan tiga eksperimen pemikiran Bagaimana untuk membahagikan tiga lapisan secara khusus, sama ada tiga lapisan, empat lapisan, atau dua lapisan, sebenarnya adalah untuk mencapai. fleksibiliti dan kebolehselenggaraan Ia hanya cara seksual

Tukar pemilihan pangkalan data

Struktur data kekal tidak berubah Berapa banyak perubahan yang diperlukan oleh projek anda apabila memindahkan pangkalan data daripada mysql ke pgsql atau bahkan mongodb?
Seni bina MVC yang ideal seharusnya tidak perlu mengubah suai sebarang kod perniagaan (termasuk Model), hanya perlu mengubah suai fail konfigurasi dan paling banyak tulis pemacu DBAL baharu
Dalam situasi sebenar, terdapat perbezaan halus dalam keupayaan DB yang berbeza, yang harus diselesaikan dengan memperhalusi Model.

Jika jawapan anda buta: ia hampir sama seperti menulis semula sekali lagi, maka lapisan M anda tidak cukup bebas, dan sudah tiba masanya untuk menyebarkan kod yang ditulis dalam Model di tempat lain

Versi HTML5 mudah alih

Dengan mengandaikan bahawa semua fungsi kekal tidak berubah (semuanya mempunyai interaksi versi mudah alih yang munasabah dan semula jadi) dan menambah versi mudah alih pada tapak anda, berapa banyak perubahan yang diperlukan oleh projek anda?
Jawapannya hendaklah menulis semula set Views, dan kemudian menukar Pengawal kepada satu barisif(isMobile) use(MobileView);

Jika anda mendapati Pengawal perlu mengubah banyak logik, malah Model terlibat, maka lapisan V anda tidak cukup bebas

Tambah API

Dengan mengandaikan bahawa semua fungsi kekal tidak berubah, berapa banyak perubahan yang diperlukan oleh projek anda jika anda menambahkan API terbuka pada tapak anda (untuk digunakan oleh pihak ketiga atau aplikasi mudah alih)?
Jawapannya mestilah set Pengawal baharu yang mengandungi kebenaran baharu, format data dan logik pengesahan serta Paparan mudah (hanya mengeluarkan json atau xml)

Jika anda mendapati Model perlu ditukar, beberapa perkara dalam Paparan asal perlu dialihkan, atau sebahagian daripada kod yang asalnya ditulis dalam Pengawal lama perlu disalin, maka lapisan C anda tidak cukup bebas

Perkara yang paling jelas dan mudah ialah membandingkan MVC dengan konsol permainan berasaskan kad yang kami mainkan semasa kecil:
M: Ini adalah kad permainan, menyimpan data, bertanggungjawab untuk logik perniagaan, dsb.
V: Ia adalah TV, bertanggungjawab untuk mempersembahkan skrin permainan
C: Ia adalah pemegang kawalan permainan, bertanggungjawab untuk interaksi antara dua yang pertama

Ambil laman web membeli-belah sebagai contoh.
M menyediakan model data Sebagai contoh, data pengguna tapak web termasuk nama pengguna, kata laluan dan alamat e-mel Setiap pengguna boleh membuat beberapa pesanan, dan setiap pesanan mempunyai nombor pesanan, harga, dsb.
V menyediakan paparan, iaitu rupa antara muka HTML yang anda lihat, seperti pembentangan senarai produk dan pembentangan pesanan sejarah peribadi.
C ialah pengawal, bertanggungjawab untuk mengekstrak data daripada M dan kemudian membentangkannya dalam V. Contohnya, apabila anda ingin menyemak sejarah pesanan peribadi anda pada minggu lalu, V bertanggungjawab mencari semua pesanan anda daripada M, menapis data pesanan dari seminggu yang lalu, dan kemudian memberikan yang selebihnya kepada V untuk paparan.

Prasyarat untuk memahami MVC ialah konsep lapisan kod, dan tujuan lapisan kod adalah penyahgandingan.

Sila cuba jawab dua soalan:

1. Kenapa kod itu perlu dipisahkan?
2. Bagaimana nak decouple?

Mengapa kod harus dipisahkan

Sesuatu perisian bermula daripada pengguna yang mencetuskan keperluan perniagaan pada paparan, kepada program yang memproses keperluan mengikut logik perniagaan tertentu, dan kemudian kepada hasil pemprosesan yang diumpan semula kepada pengguna pada paparan Kod dalam keseluruhan proses adalah bertanggungjawab untuk tiga tugas utama, iaitu: Lihat operasi, pemprosesan logik perniagaan, dan hubungan antara pandangan dan logik perniagaan.

Jika kod tidak berlapis dalam program, maka pelaksanaan ketiga-tiga aspek ini akan digabungkan dalam satu kelas. Untuk kebolehselenggaraan, kebolehbacaan dan fleksibiliti kod (sila rujuk kepada jawapan @mcfog), kod ini hendaklah ditulis ke dalam kelas yang berbeza mengikut aspek, dan kemudian kelas dengan aspek yang sama harus dimasukkan ke dalam bentuk Kelas dan pakej seperti mereka berada pada tahap yang berbeza.

Cara decouple

mvc ialah penyelesaian berlapis (decoupled) matang.

Menurut jawapan kepada soalan pertama, anda perlu meletakkan tahap kod yang berbeza ke dalam kelas (dan pakej) yang berbeza, jadi bagaimanakah tahap kod yang berbeza ini bekerjasama?

Jawapan lain untuk soalan ini nampaknya telah menjawab soalan ini secara khusus dan dengan gambar dan teks.

Kod dalam Model bertanggungjawab untuk logik perniagaan
Kod dalam View bertanggungjawab untuk interaksi pengguna
Kod dalam Pengawal bertanggungjawab untuk sambungan antara model dan pandangan.

Pandangan Model Model pengawal, pandangan, pengawal
Model: Model data
Pandangan: Elemen berkaitan UI
Pengawal: digunakan untuk menyambungkan model dan pandangan

Lebih ringkas, lebih baik, bukan?

M: Model - bagaimana anda memodelkan data, atau struktur yang digunakan untuk mewakili data anda

C: Pengawal - cara anda memproses logik perniagaan "pemprosesan" ini terutamanya sepadan dengan dua hujung: satu hujung adalah untuk meminta sumber data yang diperlukan untuk pemprosesan daripada model; cara; Proses khusus di tengah adalah tahap yang pengawal bertanggungjawab untuk

V: Lihat - cara anda membentangkan hasil pemprosesan perniagaan kepada pelanggan dan menyediakan interaksi

Sebenarnya, tidak baik untuk mengatakannya terlalu ringkas, kerana beberapa butiran hanya boleh diringkaskan dan diabstrakkan untuk kesederhanaan Tanpa pengetahuan dan pengalaman yang mencukupi untuk menyokongnya, ia seperti melihat bunga dalam kabus.

Selepas membaca jawapan semua orang di atas, akhirnya saya sedar: V adalah untuk dilihat oleh pengguna, C adalah untuk dikawal oleh pengguna, dan M tidak boleh diakses oleh pengguna. Bolehkah M dikawal melalui C dan V?

Perbincangan tentang MVC tentang SO: Apakah itu MVC, betul-betul?

Secara ringkasnya, jangan campurkan pangkalan data (Model) dan kod paparan data (Lihat) jika ada logik perniagaan yang perlu ditambah, ia adalah Pengawal (Pengawal).