Pendekatan MVC

Pengenalan kepada seni bina MVC

Seni bina aplikasi paling popular yang diketahui oleh setiap pengaturcara ialah MVC . MVC adalah singkatan dari Model-View-Controller .

Ini bukan seni bina aplikasi sebagai seni bina komponen aplikasi, tetapi kami akan kembali kepada nuansa ini kemudian. Apakah MVC?

MVC ialah skema untuk memisahkan data aplikasi dan logik kawalan kepada tiga komponen berasingan— model, paparan dan pengawal — supaya setiap komponen boleh diubah suai secara bebas.

• Model (Model) menyediakan data dan bertindak balas kepada arahan pengawal dengan menukar keadaannya.
• View bertanggungjawab untuk memaparkan data model kepada pengguna sebagai tindak balas kepada perubahan model.
• Pengawal (Pengawal) mentafsir tindakan pengguna, memberitahu model keperluan untuk perubahan.

Model ini telah dicipta pada tahun 1978 (!) Tahun. Ya, masalah dengan seni bina perisian yang betul adalah relevan 50 tahun yang lalu. Berikut ialah cara model ini diterangkan oleh rajah dalam bentuk asal:

Model ini menyediakan data dan kaedah untuk bekerja dengan mereka: pertanyaan kepada pangkalan data, menyemak ketepatan. Model ini bebas daripada pandangan (tidak tahu cara untuk memaparkan data) dan pengawal (tidak mempunyai titik interaksi pengguna), menyediakan akses kepada dan pengurusan data.

Model ini dibina sedemikian rupa untuk membalas permintaan dengan menukar keadaannya, dan pemberitahuan "pemerhati" boleh dibina. Model, disebabkan oleh kebebasan daripada perwakilan visual, boleh mempunyai beberapa perwakilan berbeza untuk satu "model".

Pandangan bertanggungjawab untuk mendapatkan data yang diperlukan daripada model dan menghantarnya kepada pengguna. Pandangan tidak memproses input pengguna.

Pengawal menyediakan "komunikasi" antara pengguna dan sistem. Mengawal dan mengarahkan data daripada pengguna ke sistem dan sebaliknya. Menggunakan model dan pandangan untuk melaksanakan tindakan yang diingini.

Terdapat kesukaran tertentu dengan fakta bahawa model ini telah berkembang sedikit selama beberapa dekad. Iaitu, nama tetap sama, tetapi tujuan bahagian mula berubah.

Seni bina MVC di web

Idea di sebalik corak reka bentuk MVC adalah sangat mudah: kita perlu memisahkan dengan jelas tanggungjawab untuk tingkah laku yang berbeza dalam aplikasi kita:

Model— pemprosesan data dan logik aplikasi.

pandangan— menyediakan data kepada pengguna dalam sebarang format yang disokong.

pengawal- memproses permintaan pengguna dan memanggil sumber yang sesuai.

Aplikasi ini dibahagikan kepada tiga komponen utama, setiap satunya bertanggungjawab untuk tugas yang berbeza. Mari kita lihat dengan lebih dekat komponen aplikasi pelayan pelanggan menggunakan contoh.

Pengawal

Pengguna mengklik pada pelbagai elemen pada halaman dalam penyemak imbas, akibatnya penyemak imbas menghantar pelbagai permintaan HTTP: GET, POST atau lain-lain. Pengawal boleh memasukkan penyemak imbas dan kod JS yang berfungsi di dalam halaman.

Fungsi utama pengawal dalam kes ini adalah untuk memanggil kaedah pada objek yang diperlukan, mengurus akses kepada sumber untuk melaksanakan tugas yang ditentukan oleh pengguna. Biasanya, pengawal memanggil model yang sesuai untuk tugas itu dan memilih paparan yang sesuai.

Model

Model dalam erti kata yang luas ialah data dan peraturan yang digunakan untuk berfungsi dengan data - bersama-sama ia membentuk logik perniagaan aplikasi. Mereka bentuk aplikasi sentiasa bermula dengan membina model objek yang dikendalikannya.

Katakan kita mempunyai kedai dalam talian yang menjual buku, maka adakah seseorang itu hanya pengguna aplikasi atau juga pengarang buku? Soalan penting ini mesti ditangani semasa reka bentuk model.

Selanjutnya terdapat set peraturan: apa yang boleh dilakukan, apa yang tidak boleh dilakukan, set data mana yang boleh diterima dan mana yang tidak. Bolehkah buku wujud tanpa pengarang? Dan pengarang tanpa buku? Bolehkah tarikh lahir pengguna pada tahun 300 dan seterusnya.

Model memberikan pengawal pandangan data yang diminta oleh pengguna (mesej, halaman buku, gambar, dll.). Model data akan sama tidak kira bagaimana kita mahu membentangkannya kepada pengguna. Oleh itu, kami memilih mana-mana paparan yang tersedia untuk memaparkan data.

Model ini mengandungi bahagian paling penting dalam logik aplikasi kami , logik yang menyelesaikan masalah yang kami hadapi (forum, kedai, bank, dll.). Pengawal mengandungi kebanyakan logik organisasi untuk aplikasi itu sendiri (sama seperti Pengurus Projek anda).

Lihat

View menyediakan pelbagai cara untuk mewakili data yang diterima daripada model. Ia boleh menjadi templat yang diisi dengan data. Terdapat beberapa pandangan berbeza dan pengawal memilih mana yang terbaik untuk situasi semasa.

Aplikasi web biasanya terdiri daripada satu set pengawal, model dan pandangan. Pengawal hanya boleh berada di bahagian belakang, tetapi terdapat juga varian beberapa pengawal, apabila logiknya juga tersebar di bahagian hadapan. Contoh yang baik bagi pendekatan ini ialah sebarang aplikasi mudah alih.

Contoh MVC di web

Katakan anda perlu membangunkan kedai dalam talian yang akan menjual buku. Pengguna boleh melakukan tindakan berikut: melihat buku, mendaftar, membeli, menambah item pada pesanan semasa, menanda buku yang dia suka dan membelinya.

Aplikasi anda harus mempunyai model yang bertanggungjawab untuk semua logik perniagaan. Anda juga memerlukan pengawal yang akan memproses semua tindakan pengguna dan mengubahnya menjadi panggilan kaedah daripada logik perniagaan. Walau bagaimanapun, satu kaedah pengawal boleh memanggil banyak kaedah model yang berbeza.

Anda juga memerlukan set paparan: senarai buku, maklumat tentang satu buku, troli beli-belah, senarai pesanan. Setiap halaman aplikasi web sebenarnya adalah paparan berasingan yang memaparkan aspek tertentu model kepada pengguna.

Mari lihat apa yang berlaku jika pengguna membuka senarai buku yang disyorkan kedai buku untuk melihat tajuk. Seluruh urutan tindakan boleh diterangkan dalam bentuk 6 langkah:

Langkah-langkah:

1. Pengguna mengklik pada pautan "disyorkan" dan penyemak imbas menghantar permintaan kepada, katakan, /books/recommendations.
2. Pengawal menyemak permintaan : pengguna mesti log masuk. Atau kita sepatutnya mempunyai koleksi buku untuk pengguna yang tidak log masuk. Pengawal kemudian memanggil model dan memintanya mengembalikan senarai buku yang disyorkan kepada pengguna N.
3. Model itu mengakses pangkalan data, mendapatkan maklumat tentang buku dari sana: buku yang popular pada masa ini, buku yang dibeli oleh pengguna, buku yang dibeli oleh rakannya, buku dari senarai keinginannya. Berdasarkan data ini, model membina senarai 10 buku yang disyorkan dan mengembalikannya kepada pengawal.
4. Pengawal menerima senarai buku yang disyorkan dan melihatnya. Pada peringkat ini, pengawal membuat keputusan! Jika terdapat sedikit buku atau senarai itu kosong sepenuhnya, maka ia meminta senarai buku untuk pengguna yang tidak dilog. Jika ada promosi sedang berlangsung sekarang, pengawal boleh menambah buku promosi pada senarai.
5. Pengawal menentukan halaman yang hendak ditunjukkan kepada pengguna. Ia boleh menjadi halaman ralat, halaman dengan senarai buku, halaman yang mengucapkan tahniah bahawa pengguna telah menjadi pelawat ke juta.
6. Pelayan memberikan klien halaman ( view ) yang dipilih oleh pengawal. Ia diisi dengan data yang diperlukan (nama pengguna, senarai buku) dan pergi ke pelanggan.
7. Pelanggan menerima halaman dan memaparkannya kepada pengguna.

Apakah faedah pendekatan ini?

Kelebihan paling jelas yang kami dapat daripada menggunakan konsep MVC ialah pemisahan logik pembentangan (antara muka pengguna) dan logik aplikasi (backend) yang jelas.

Kelebihan kedua ialah pembahagian bahagian pelayan kepada dua: model pintar ( pelaksana ) dan pengawal ( pusat keputusan ).

Dalam contoh sebelumnya, terdapat satu ketika pengawal boleh menerima senarai kosong buku yang disyorkan daripada model dan memutuskan perkara yang perlu dilakukan dengannya. Secara teorinya, logik ini boleh dimasukkan terus ke dalam model.

Pertama, apabila meminta buku yang disyorkan, model akan memutuskan perkara yang perlu dilakukan jika senarai itu kosong. Kemudian saya perlu menambah kod di tempat yang sama, apa yang perlu dilakukan jika ada promosi sedang berlaku sekarang, kemudian lebih banyak pilihan yang berbeza.

Kemudian ternyata admin kedai ingin melihat bagaimana muka halaman pengguna tanpa promosi, atau sebaliknya, tiada promosi sekarang, tetapi dia ingin melihat bagaimana promosi akan datang akan dipaparkan. Dan tidak ada kaedah untuk ini. Oleh itu, ia telah memutuskan untuk memisahkan pusat keputusan (pengawal) daripada logik perniagaan (model).

Selain mengasingkan pandangan daripada logik aplikasi, konsep MVC sangat mengurangkan kerumitan aplikasi besar. Kod ini lebih tersusun, menjadikannya lebih mudah untuk mengekalkan, menguji dan menggunakan semula penyelesaian.

Memahami konsep MVC, anda, sebagai pembangun, menyedari di mana anda perlu menambah pengisihan senarai buku:

• Pada peringkat pertanyaan pangkalan data.
• Pada peringkat logik perniagaan (model).
• Pada peringkat logik perniagaan (pengawal).
• Dalam pandangan - di sebelah pelanggan.

Dan ini bukan soalan retorik. Sekarang, fikirkan tentang di mana dan mengapa anda perlu menambah kod untuk mengisih senarai buku.

Model MVC Klasik

Interaksi antara komponen MVC dilaksanakan secara berbeza dalam aplikasi web dan aplikasi mudah alih. Ini kerana apl web berumur pendek, memproses satu permintaan pengguna dan keluar, manakala apl mudah alih memproses banyak permintaan tanpa dimulakan semula.

Aplikasi web biasanya menggunakan model "pasif", manakala aplikasi mudah alih menggunakan model "aktif". Model aktif, tidak seperti yang pasif, membolehkan anda melanggan dan menerima pemberitahuan perubahan di dalamnya. Ini tidak diperlukan untuk aplikasi web.

Beginilah rupa interaksi komponen dalam pelbagai model:

Aplikasi mudah alih (model aktif) secara aktif menggunakan acara dan mekanisme langganan acara. Dengan pendekatan ini, view ( view ) melanggan perubahan model. Kemudian, apabila beberapa peristiwa berlaku (contohnya, pengguna mengklik butang), pengawal dipanggil . Ia juga memberikan model arahan untuk menukar data.

Jika sesetengah data telah berubah, maka model menjana peristiwa tentang menukar data ini. Semua paparan yang telah melanggan acara ini (yang mana adalah penting untuk menukar data tertentu ini) menerima acara ini dan mengemas kini data dalam antara muka mereka.

Dalam aplikasi web, perkara diatur sedikit berbeza. Perbezaan teknikal utama ialah pelanggan tidak boleh menerima mesej sebelah pelayan atas inisiatif pelayan .

Oleh itu, pengawal dalam aplikasi web biasanya tidak menghantar sebarang mesej ke paparan, tetapi memberikan pelanggan halaman baharu, yang secara teknikalnya merupakan paparan baharu atau bahkan aplikasi pelanggan baharu (jika satu halaman tidak mengetahui apa-apa tentang halaman yang lain) .

Pada masa ini, masalah ini sebahagiannya diselesaikan menggunakan pendekatan berikut:

• Mengundi secara kerap pelayan untuk perubahan pada data penting (sekali seminit atau lebih).
• WebSockets membenarkan pelanggan melanggan mesej pelayan.
• Pemberitahuan tolak web dari bahagian pelayan.
• Protokol HTTP/2 membenarkan pelayan untuk memulakan penghantaran mesej kepada klien.