Jelaskan MVC kepada yang bukan pemrogram [ditutup]


31

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?



12
Nyatakan bahwa itu "Praktik terbaik" dan mereka akan bahagia.
Johan

2
Jika saya harus menggambarkannya dalam istilah yang disederhanakan, saya akan menggambarkannya sebagai pola arsitektur yang berfokus pada pemisahan masalah - ini, pada gilirannya, memungkinkan pengembang frontend untuk fokus pada frontend, pengembang backend untuk fokus pada backend dan pengembang database untuk fokus pada database, tanpa mengganggu satu sama lain sebanyak yang mereka lakukan dalam sistem yang terstruktur berbeda.
Theodoros Chatzigiannakis

2
Bagaimana Anda akan menjelaskan, jika Anda tidak sepenuhnya memahami apa itu?
BЈовић

Saya pikir mungkin ada analogi yang dibuat dengan aspek bagian yang dapat dipertukarkan dari revolusi industri ... pasti mereka dapat memahami manfaat dari dapat mengebor dan mengetuk lubang 1 / 4-20 tanpa harus khawatir tentang apakah atau tidak baut akan cocok.
J ...

Jawaban:


70

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.


13
TKI jelaskan kebutuhannya restrukturisasi ke MVC (itu hebat: berbicara bahasa mereka kepada mereka )
Wolf

4
Sering membantu untuk menyebutkan kasus-kasus di mana perbaikan bug dan permintaan fitur akan lebih cepat (lebih murah) jika basis kode memiliki pemisahan keprihatinan yang tepat.
Eric Wilson

14
Saya pikir akan bermanfaat untuk membuat lompatan berikutnya dan menyarankan bahwa bahasa yang digunakan adalah $ £ ¥ € ƒруб. Jika Anda menjelaskannya kepada non-programmer, itu mungkin dalam konteks bisnis dan sangat mungkin bahwa itu bermuara pada "ke mana uang itu pergi"?
Joel Etherton

Mungkin membantu untuk membandingkan dengan sesuatu yang mereka ketahui. "Kami merestrukturisasi untuk mencocokkan prinsip-prinsip organisasi yang diadopsi secara luas, seperti konvensi yang telah diselesaikan oleh komunitas akuntansi."
Nathan

41

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.


4
So, have a sketch of MVC in your hip pocket, ready to go.- atau mungkin Presentasi pp ;-) untuk pengguna "bahasa mereka"?
Wolf

Saya tidak akan mengatakan bahwa "model bertanggung jawab atas data inti dan logika bisnis," sama sekali. Logika bisnis sebaiknya disimpan terpisah ke dalam lapisannya sendiri. Faktanya, model hanyalah kumpulan data yang dilewatkan dari controller ke view, untuk memisahkan kedua layer tersebut. Misalnya, Anda hampir tidak pernah melewatkan objek ORM tunggal ke tampilan, tetapi satu set dari mereka, ditambah beberapa data lain-lain. Lihat jawaban saya untuk penjelasan yang lebih panjang.
Tobia

2
@Tobia Itulah yang disebut Microsoft Model. "The" model adalah model komputer presentasi-agnostik dari sistem yang berinteraksi dengan pengguna, jadi hampir semua yang bukan bagian dari tampilan dan pengontrol.
Doval

@Doval Itu mungkin interpretasi Microsoft, tapi itu adalah pembatasan dari generalisasi MVC. Lihatlah kerangka kerja MVC lincah seperti Ruby on Rails, Django, atau Grails, untuk melihat apa yang saya maksud. Saya telah memperluas jawaban saya lagi untuk menutupi kesalahpahaman umum ini.
Tobia

3
Dalam pola Smalltalk MVC asli, setiap kontrol pada layar memiliki model, tampilan, dan pengontrol sendiri. Jangan berpura-pura ada definisi tunggal MVC yang disetujui semua orang. Untungnya, dia hanya perlu menjelaskan apa yang dia lakukan.
RemcoGerlich

9

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.


9
  • 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.


Hmmm ... analogi itu tidak benar-benar "memukul tempat" IMHO.
DevSolar

Tetapi seluruh gagasan tentang menyediakan semacam analogi adalah itu. Saya akan menulis sesuatu yang serupa. Biasanya sesuatu yang melibatkan mobil atau uang bekerja dengan sangat baik ... :-)
JensG

Sungguh orang-orang yang harus upvoting adalah yang bukan pemrogram. Saya pikir sebagian besar pengguna situs adalah programmer! :)
Jon Raynor

3

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.

masukkan deskripsi gambar di sini

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.


3

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.


Jika perusahaan OP tidak terorganisir dengan baik, maka saya sarankan kepadanya untuk berbicara tentang "pembagian kerja" di sepanjang garis kemajuan ekonomi umum, misalnya pemburu / pengumpul berubah menjadi pekerja khusus seperti pengembang perangkat lunak :)
logc

Deskripsi yang baik - penafian yang sangat baik.
citizenkong

2

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.


4
Saya tidak akan menyamakan Model MVC dengan database, atau Pengontrol MVC dengan input pengguna.
Tobia

1
@Tobia Ya, tapi nuansa itu akan hilang pada orang non-teknis. Ia mendapat intinya
B2K

@Tobia meninjau kembali ini, deskripsi yang disesuaikan agar lebih akurat. Terima kasih atas komentar anda
B2K

1

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.


1

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.