Saya perlu menjelaskan MVC kepada yang bukan programmer. Yaitu, untuk manajer departemen lain, dalam konteks laporan kemajuan. Salah satu hal yang saya lakukan adalah memperbaiki basis kode kami menuju pemisahan MVC.

Apa pemisahan MVC yang mungkin mereka tanyakan? Mengapa perlu mereka bertanya?

Setelah membaca jawaban yang cukup teknis seperti ini: Apa itu MVC? , Saya tidak sepenuhnya puas, karena saya akan berbicara dengan non-programmer. Mereka mungkin menganggukkan kepala tetapi mereka mungkin tidak akan mengerti apa itu dan mengapa itu diperlukan.

Pada kenyataannya, saya tidak sepenuhnya memahami apa itu MVC selain dari "pemisahan masalah, tugas, fungsi, kelas, blok, tugas, hal-hal, dalam rangka meningkatkan fleksibilitas membuat perubahan pada perangkat lunak". Memisahkan basis data dari tampilan dan tampilan dari logika bisnis menggunakan teknik seperti alat dan teknik DI dan OO adalah sesuatu yang saya anggap sebagai pemisahan MVC.

Jadi lain kali Anda menjelaskan MVC kepada non-programmer yang memiliki latar belakang dalam penjualan dan akuntansi misalnya, apa yang akan Anda katakan kepada mereka?

Anda tidak menjelaskan MVC.

Apa yang Anda lakukan adalah menjelaskan bahwa ini adalah restrukturisasi basis kode.

Restrukturisasi yang menyederhanakan basis kode dan karenanya memungkinkan pengembang untuk membuat perubahan lebih cepat dan lebih baik pada laporan bug dan permintaan fitur, dengan bug lebih sedikit.

Mereka tidak perlu mengetahui detail teknis, hanya mengapa itu dilakukan, apa yang dicapai dengan melakukannya dan bagaimana manfaat bisnis.

Dengan kata lain - ucapkan bahasa mereka kepada mereka.

Sementara saya mendukung inti jawaban Oded , bahwa Anda harus menjelaskan proyek teknis kepada manajer bisnis dalam "bahasa mereka," saya memiliki keraguan tentang "mereka tidak perlu mengetahui detail teknis, hanya mengapa itu dilakukan."

Jika Anda berada dalam pertemuan tinjauan proyek atau investasi dengan kepala departemen, dan Anda menyatakan "ini yang kami lakukan," mereka mungkin ingin bertanya "Umm ... kenapa? Itu sepertinya investasi besar waktu dan energi. Bisakah Anda memberi kami sedikit lebih memahami apa yang Anda lakukan dan mengapa? " Itu tampaknya pertanyaan yang sangat masuk akal. Anda tidak ingin terjebak dalam posisi "Yah ... itu rumit." atau "Tidak, saya tidak bisa menjelaskannya." atau "Jangan khawatir tentang hal itu." Semakin senior staf yang Anda lakukan untuk tinjauan proyek, semakin kecil kemungkinan mereka membiarkan "hanya hal-hal yang tidak bisa saya jelaskan dengan baik". Lebih baik jika Anda bisa naik setidaknya satu tingkat lebih dalam untuk membuat orang lain merasa nyaman bahwa 1) Anda tahu apa yang Anda

Jadi, miliki sketsa MVC di saku pinggul Anda, siap untuk digunakan. Sesuatu seperti:

"Ini sedikit teknis, tapi ... MVC membagi kode menjadi Model (bertanggung jawab atas data inti dan logika bisnis), Views (yang menampilkan data), dan Controllers (yang menangani interaksi dan pembaruan pengguna). Ini arsitektur yang terbukti - "Pola desain" yang paling sukses dari rekayasa perangkat lunak. Saya tahu ini mungkin tampak seperti "hanya pipa ledeng," tetapi untuk menangani semua permintaan yang masuk, kita membutuhkan fondasi yang lebih kuat. Ini akan menempatkan kita pada pijakan yang tepat untuk membangun yang baru fitur dan mengatasi bug lebih cepat. "

Bahkan jika mereka tidak sepenuhnya memahami MVC di bagian akhir, dan bahkan jika Anda harus terlalu menyederhanakan untuk membuatnya dipahami ("pecahkan beberapa telur untuk membuat telur dadar"), saya bertaruh Anda akan merasa jauh lebih nyaman untuk menggunakan MVC. siapkan penjelasan daripada harus mengatakan "Saya tidak bisa menjelaskannya" atau "Anda tidak memenuhi syarat untuk memahaminya" kepada manajer senior.

untuk meningkatkan fleksibilitas dalam membuat perubahan pada perangkat lunak

Manajer tertarik pada hasil akhirnya. Semakin sedikit teknis mereka semakin kecil kemungkinan mereka peduli dengan bagaimana Anda sampai di sana. MVC sangat umum, populer dan terbukti.

Saat permintaan perubahan dibuat di masa mendatang, Anda dapat memberi tahu manajemen bahwa permintaan itu dapat dibuat lebih mudah dan lebih cepat. Semua orang suka mendengar ini.

Ini adalah strategi umum, jadi merekrut pengembang baru seharusnya tidak menimbulkan masalah. Bahkan, Anda dapat menarik pengembang yang lebih baik yang merupakan pendukung kuat.

Ini semua akan menjadi sangat sulit jika ada banyak masalah mendesak dalam proyek khusus ini. Mereka mungkin tidak ingin mengambil langkah mundur sehingga Anda dapat mengambil dua langkah ke depan. Pada solusi mungkin menunggu atau menerapkan dalam potongan yang lebih kecil.

• Model - Kabel / listrik
• Lihat - Lampu
• Controller - Sakelar Lampu

Komponen yang relatif mudah untuk dimatikan (lampu, sakelar / dimmer). Mungkin tidak begitu banyak kabel, tetapi masih bisa dilakukan tanpa mempengaruhi komponen lain. Setiap orang harus dapat memvisualisasikan hal itu di kepala mereka, bahkan tipe pemasaran / penjualan. (Hapus pemisahan, dll.)

Sekarang beri tahu atasan / rekan kerja Anda bahwa dalam aplikasi / sistem kita sakelar tertanam di dalam lampu dan lampu dipasang di kawat tembaga. Sekarang bayangkan mencoba memperbarui lampu, saklar, atau kabel. Sangat mahal, dampak ke komponen lain sangat tinggi dan mungkin berbahaya untuk dilakukan tanpa merusak sesuatu yang lain.

MVC menerapkan pola pada basis kode yang mengubah kekacauan yang campur aduk (tetapi berfungsi) menjadi sesuatu di mana perubahan dapat terjadi lebih cepat dan lebih mudah dengan lebih sedikit kesalahan.

Cara mudah untuk memahami MVC: yang model data , yang melihat adalah jendela pada layar , dan kontroler adalah perekat antara dua .

Rubrik terbaik yang pernah ada: "Kami membutuhkan Model SMART, Pengontrol TIPIS, dan Tampilan DUMB"

Seperti pola desain perangkat lunak lainnya, MVC mengekspresikan " inti dari solusi " untuk masalah sambil memungkinkannya untuk diadaptasi untuk setiap sistem. Lebih baik dilihat sebagai konsep daripada implementasi spesifik. Ada banyak implementasi konsep.

Semua varian MVC menggunakan divisi komponen yang sama, tetapi biasanya mereka berbeda dalam cara komponen-komponen tersebut berinteraksi.

Bagi Anda yang tidak sadar, MVC pada awalnya dijelaskan dalam hal pola desain untuk digunakan dengan Smalltalk oleh Trygve Reenskaug pada tahun 1979 . Makalahnya diterbitkan dengan judul "Pemrograman Aplikasi di Smalltalk-80: Cara menggunakan Model-View-Controller", dan membuka dasar untuk sebagian besar implementasi MVC di masa depan.

Saya setengah setuju dengan Oded - mempelajari cara meyakinkan rekan dan manajer non-teknis Anda bahwa apa yang Anda lakukan adalah penting dan berguna, tanpa menjelaskan perincian yang kasar, adalah keterampilan yang diperlukan yang akan Anda kembangkan dengan bijaksana.

Namun, saya percaya bahwa memiliki kemampuan untuk menjelaskan konsep kompleks dalam istilah sederhana sebenarnya membantu dengan itu - satu masalah yang sering dimiliki manajer non-teknis adalah bahwa karena mereka mengalami kesulitan memahami dengan tepat apa yang dilakukan orang-orang teknologi, mereka memiliki kecenderungan untuk tidak mempercayai mereka. Itu hanya sifat manusia: lebih mudah untuk percaya bahwa sesuatu yang Anda tidak mengerti tidak berguna atau salah daripada menaruh kepercayaan Anda padanya. Oleh karena itu, jika Anda dapat membuat konsep mudah dimengerti sesuka hati, Anda dapat menggunakannya kapan pun Anda membutuhkannya, dan seiring waktu, manajer non-teknis Anda akan belajar bahwa mereka dapat memahaminya jika mereka mau - Anda tidak menariknya pada mereka - Anda hanya memberi mereka detail untuk kewarasan mereka sendiri. Mereka akan lebih mempercayaimu.

Selain itu, mari kita jawab pertanyaannya:

Saya merasa berguna untuk menggunakan analogi yang dipahami pebisnis. Untuk MVC, saya menggambarkannya sebagai bisnis.

• Model bertanggung jawab atas logika dan data bisnis - mereka adalah hal-hal yang menentukan apa yang dilakukan oleh program dan perincian bagaimana melakukannya. Jika program itu bisnis, maka modelnya adalah gudang, pabrik, pekerja, dan peralatan modal. Mereka juga akan menjadi manajer tingkat bawah yang memastikan aturan dipatuhi dan kebijakan ditegakkan.
• Tampilan adalah lapisan presentasi - mereka menunjukkan kepada pengguna apa yang terjadi dalam sistem dan menyediakan sarana untuk berinteraksi dengan program. Jika program kami adalah perusahaan, pandangan akan seperti lantai ruang pamer, stan penjualan di konvensi perdagangan, atau perwakilan penjualan. Mereka menampilkan opsi, memberikan informasi dan umpan balik yang ramah pengguna, dan menerima permintaan kembali ke perusahaan.
• Pengendali adalah lapisan koordinasi - mereka memastikan bahwa informasi masuk dari model ke tampilan dan sebaliknya, dan bahwa semuanya bekerja bersama untuk melakukan pekerjaan mereka. Jika program tersebut adalah perusahaan, maka pengendali akan menjadi manajemen tingkat menengah dan tinggi. Mereka tidak terlalu terlibat dalam perincian, tetapi mereka memastikan bahwa orang yang tepat memiliki alat yang tepat untuk melakukan pekerjaan mereka, dan mereka menyetujui atau menolak keputusan tingkat tinggi. Mereka memberikan arahan keseluruhan sehingga hal-hal dapat bekerja bersama.

Manfaat untuk menjelaskannya dengan analogi ini adalah bahwa manajer yang baik akan melihat kebijaksanaan dalam memisahkan masalah dengan cara ini, dan mungkin memutuskan bahwa mereka harus lebih seperti pengontrol, dan tidak terlalu terlibat dalam detail di masa depan!

Mudah-mudahan itu akan menjawab "apa" - "mengapa" juga mudah dengan analogi ini:

Bayangkan sebuah perusahaan yang ideal, di mana setiap departemen bertanggung jawab untuk satu set tugas, dan tahu bahwa ia akan selalu memiliki sumber daya yang dibutuhkan tanpa harus khawatir tentang apa yang dilakukan orang lain. Seorang tenaga penjualan menemukan seorang pelanggan, mendapatkan pesanan mereka, menyerahkannya kembali kepada manajemen yang menyetujui, dan kemudian pergi ke gudang / produksi / teknik untuk pemenuhan. Umpan balik langsung - tidak ada orang lain yang perlu terlibat kecuali ada masalah. Itu desain MVC yang bagus - setiap bagian memiliki pekerjaan, dan tidak perlu khawatir tentang bagian lain. Dengan begitu, mudah untuk berubah jika perlu. Dalam desain non-MVC, tanggung jawab tidak jelas. Tenaga penjualan mungkin mencoba untuk memodifikasi produk ketika pelanggan meminta sesuatu yang berbeda. Atau mereka mungkin memberikan harga yang berbeda tergantung pada apa yang mereka rasakan hari itu. CEO mungkin turun di lantai pabrik mengacaukan jalur produksi, ketika dia harus khawatir tentang cara mendapatkan rantai pasokan yang lebih andal. Pekerja gudang mungkin keluar di lantai penjualan berbicara dengan pelanggan ketika mereka harus memenuhi pesanan yang sudah diambil.

Dengan kata lain, desain MVC yang baik memungkinkan setiap bagian fokus pada satu hal, sehingga dapat melakukannya dengan benar - seperti perusahaan yang terorganisir dengan baik.

** Penafian - jika perusahaan Anda tidak terorganisir dengan baik, mereka mungkin tersinggung oleh ini. Dalam hal ini, Anda perlu analogi lain. Anda mungkin juga membutuhkan pekerjaan yang berbeda.

Manfaat MVC terutama dalam pemisahan masalah:

Ini memungkinkan orang berkonsentrasi pada apa yang mereka lakukan terbaik.

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

Ini menurunkan biaya karena sistem yang saling terkait membutuhkan staf untuk menjadi ahli di semua bidang ini, atau Anda lebih cenderung memiliki masalah ketika perubahan pada satu bidang memengaruhi yang lain.

Berikan contoh nyata dari arsitektur MVC: Telepon Seluler, Telepon Desktop, Skype, dll. Mengubah Tampilan (jenis papan tombol, speaker, mikrofon) tidak mempengaruhi model (sinyal audio), pengontrol adalah sirkuit dalam telepon yang menerjemahkan gelombang suara menjadi sinyal audio.

Saya akan memberitahu mereka bahwa MVC memisahkan kekhawatiran saya.

Perhatian pertama saya adalah logika kode - apa yang saya lakukan di balik layar untuk membuat situs web melakukan tindakan yang mereka inginkan.

Perhatian kedua saya adalah logika bisnis - apa yang mereka (pengguna) inginkan agar aplikasi lakukan.

Kekhawatiran ketiga saya adalah bagaimana situs itu terlihat - Halaman yang mereka kunjungi untuk melakukan apa yang mereka inginkan.

(Saya tidak akan memberi tahu mereka bagian selanjutnya) Jadi, agar, penjelasan saya adalah untuk Model, Controller, dan View.

Jelaskan keuntungannya

Saya akan menjelaskan MVC dalam hal manfaat bisnis. Manajer Anda akan dapat memahami hal ini, dan akan bergabung jika keuntungannya meyakinkan.

MVC memungkinkan Anda untuk memecah aplikasi Anda menjadi unit yang masuk akal, masing-masing ada secara terpisah dari yang lain. Anda menjadi bersih, dapat dipelihara, kode yang dapat diuji, dan berpotensi menggunakan kembali kode antar sistem.

Model

Setiap model merangkum satu jenis informasi bisnis, misalnya, catatan pelanggan atau produk, bersama dengan semua logika bisnis terkait.

Memisahkan ini memungkinkan Anda untuk dengan mudah menguji logika bisnis Anda secara terpisah dari bagian lain dari aplikasi Anda.

Anda juga dapat dengan mudah memperpanjang aplikasi dengan menambahkan model tambahan, sangat modular dan bersih.

Setiap model dalam teori dapat eksis secara independen dari yang lain. Anda mungkin mempertimbangkan memberlakukan ini dengan menggunakan objek layanan untuk menangani hubungan antar model. Anda dapat menukar model tanpa memengaruhi sistem lainnya.

Pandangan

Dengan memisahkan tampilan Anda, Anda dapat dengan mudah memperbarui ujung depan tanpa merusak ujung belakang yang mendasarinya.

Anda dapat memberikan kode ujung depan ke pengembang lain tanpa harus memberi mereka akses ke seluruh sistem.

Anda juga bebas membuat ujung depan alternatif yang berfungsi dengan sistem yang ada. Anda mungkin memperlihatkan data Anda sebagai aplikasi seluler, atau API, atau PDF, atau spreadsheet Excel. Anda dapat melakukan ini tanpa meretas ke bagian lain dari sistem. Anda cenderung merusak barang-barang secara tidak sengaja. Anda dapat dengan mudah membuat titik integrasi untuk dihubungkan dengan sistem yang ada.

Pengendali

Pengontrol kabel model ke tampilan. Itu membuat semuanya terpisah. Anda dapat menghubungkan tampilan yang berbeda dengan sangat mudah. Jika Anda mengubah kode model Anda, tampilan bahkan tidak perlu tahu.

Keuntungan lainnya

Itu adalah pola umum. Pengembang lain akan dapat memahami kode Anda dan mengerjakannya. Jika Anda kembali ke kode Anda bertahun-tahun kemudian, Anda mungkin dapat memahaminya dan membuat perubahan. Kode Anda akan cenderung menjadi pusing pusaka lagi untuk pengembang di masa depan.

Karena semuanya memiliki tempat, jauh lebih mudah untuk menghasilkan kode bersih. Risiko spagettifikasi berkurang secara dramatis (meskipun tidak dihilangkan). Kode Anda menjadi terpelihara.

Karena semuanya modular, Anda dapat menguji bagian-bagiannya secara terpisah. Kode Anda dapat diuji dan kecil kemungkinannya mengandung bug atau lubang keamanan. Peningkatan di masa mendatang akan jauh lebih mudah karena Anda akan dapat dengan mudah menguji keseluruhan sistem.