Mengapa saya harus menggunakan pola MVC?


74

Sepertinya semua orang melakukan aplikasi web saat ini ingin menggunakan MVC untuk semuanya. Namun, saya sulit meyakinkan diri saya untuk menggunakan pola ini. Saya mengerti ide umum adalah untuk memisahkan logika backend dari frontend yang mewakili program. Secara umum, tampaknya pandangan selalu bergantung pada pengontrol sampai batas tertentu, yang akhirnya tergantung pada model. Saya tidak melihat apa manfaatnya dengan menambahkan pengontrol. Saya sudah membaca banyak hype tentang "ini adalah cara aplikasi harus dirancang", tapi mungkin saya masih tidak mengerti apa yang seharusnya pergi ke mana. Setiap kali saya berbicara dengan orang lain tentang MVC, tampaknya setiap orang memiliki ide yang berbeda tentang apa yang termasuk dalam kategori apa.

Jadi, mengapa saya harus menggunakan MVC? Apa yang saya dapatkan dengan menggunakan MVC hanya dengan memisahkan frontend dari logika backend? (Sebagian besar "keuntungan" yang saya lihat dari pola ini diperoleh hanya dengan memisahkan antarmuka dari implementasi, dan gagal menjelaskan tujuan memiliki "pengontrol" terpisah)


9
MVC hanyalah implementasi dari Seperation of Concerns . Setiap implementasi akan dilakukan. Tidak menggunakan Seperations of Concerns cenderung mengarah ke bola besar Lumpur
Raynos

1
@ Raynos: Mungkin. Tapi itu bukan tujuan "hype".
Billy ONeal

3
hype mematuhi kurva hype . Jangan biarkan itu terlalu memengaruhi Anda. Dari sudut pandang saya, MVC adalah arsitektur yang solid untuk SoC dan mudah diimplementasikan. Saya tidak bisa memikirkan alternatif yang solid.
Raynos

sebagian besar kerangka kerja antarmuka pengguna yang ada menghubungkan dengan erat V dan C dan ketika Anda beralih ke yang lain, Anda harus menulis ulang tampilan dan pengontrol (antarmuka dari M ke apa yang dilihat pengguna)
ratchet freak

Tapi Pemisahan Kekhawatiran adalah properti dari pengembangan OO. Anda tidak harus menggunakan pola MVW untuk menerapkan kode Pemisahan Kekhawatiran yang benar?
Bastien Vandamme

Jawaban:


50

Heh. Martin Fowler setuju dengan kebingungan Anda tentang MVC:

Saya tidak merasa sangat berguna untuk memikirkan MVC sebagai pola karena mengandung beberapa ide yang berbeda. Orang yang berbeda yang membaca tentang MVC di tempat yang berbeda mengambil ide yang berbeda darinya dan menggambarkannya sebagai 'MVC'. Jika ini tidak menyebabkan kebingungan yang cukup Anda kemudian mendapatkan efek kesalahpahaman MVC yang berkembang melalui sistem bisikan Cina.

Namun, ia kemudian memberikan salah satu penjelasan yang lebih meyakinkan tentang apa yang memotivasi MVC:

Inti dari MVC adalah apa yang saya sebut Presentasi Terpisah. Gagasan di balik Presentasi Terpisah adalah untuk membuat pembagian yang jelas antara objek domain yang memodelkan persepsi kita tentang dunia nyata, dan objek presentasi yang merupakan elemen GUI yang kita lihat di layar. Objek domain harus benar-benar mandiri dan berfungsi tanpa mengacu pada presentasi, mereka juga harus dapat mendukung banyak presentasi, mungkin secara bersamaan.

Anda dapat membaca seluruh artikel Fowler di sini .


19

Saya merasa ini sangat tergantung pada masalah yang Anda tangani. Saya melihat pemisahan sebagai berikut:

Model - bagaimana kita merepresentasikan data? Sebagai contoh, bagaimana cara saya beralih dari objek saya ke penyimpanan yang persisten seperti DB -> bagaimana cara menyimpan objek 'Pengguna' saya ke database?

Kontroler - apa yang saya lakukan? Ini adalah tindakan yang sedang terjadi, dan apa, pada tingkat konseptual, perlu dilakukan. Misalnya, tahap apa yang harus saya lalui untuk menagih Pengguna? NB ini dapat mempengaruhi jumlah objek, tetapi tidak tahu apa-apa tentang bagaimana mereka bertahan ke DB.

Lihat - bagaimana cara membuat hasilnya?

Masalah yang saya rasa Anda lihat adalah bahwa banyak aplikasi web adalah antarmuka CRUD (Create-Retrieve-Update-Delete) yang dimuliakan ke DB. yaitu pengendali diberitahu untuk 'menambahkan pengguna', dan kemudian hanya memberitahu model untuk 'menambah pengguna'. Tidak ada yang diperoleh.

Namun, dalam proyek-proyek di mana tindakan yang Anda lakukan tidak berlaku secara langsung untuk perubahan dalam model pengontrol membuat hidup lebih mudah dan sistem lebih dapat dipertahankan.


1
"dalam proyek-proyek di mana tindakan yang Anda lakukan tidak berlaku langsung pada perubahan dalam model" Apa yang Anda maksud dengan "model" di sini? Data? Karena semua orang yang saya ajak bicara mengatakan bahwa tindakan seperti itu masih termasuk dalam model, bukan di controller. (mis. pengendali itu hanya berurusan dengan hal-hal HTTP ...)
Billy ONeal

Apa yang dianggap sebagai barang HTTP? Saya akan memasukkan yang berikut ini dalam sebuah pengontrol: Membatalkan permintaan parameter HTTP, memeriksa parameter untuk kewarasan dasar, menentukan apa yang perlu dilakukan, mengunjungi objek model yang sesuai (untuk membaca, menulis atau keduanya), menghasilkan hasil akhir berdasarkan respon model , menyampaikannya ke tampilan. Contoh konyol dari sesuatu yang hanya akan digunakan oleh pengontrol adalah layanan web yang menghasilkan angka acak - dalam hal ini tidak ada 'model' untuk dilihat (setidaknya dalam pikiran saya ...)
Unk

Itu semua adalah model perhatian. Bahkan "memutuskan apa yang perlu dilakukan" ("pengontrol depan") adalah model.
Billy ONeal

2
Belum lagi kontroler berguna untuk tidak menyambungkan model Anda dengan tampilan Anda. Serta memungkinkan Anda untuk menghubungkan banyak tampilan ke banyak model melalui satu pengontrol.
Raynos

1
@Billy: jika Anda mengizinkan tampilan untuk "mengacaukan" model - selain meminta nilai-nilainya - Anda berakhir dengan tampilan yang lebih seperti pengontrol. Saya berpikir lebih dalam hal inkarnasi MVC Model-GUI-Mediator. Pengontrol memediasi antara Model (perilaku dan data domain) dan GUI (representasi model di layar). Tampilan hanya meneruskan interaksi ke controller (pengguna mengklik ...). Pengontrol memutuskan apa (jika ada) yang perlu dipanggil pada model. Manfaat: ...
Marjan Venema

8

Anda seharusnya tidak.

Biarkan saya ulangi lagi. Anda harus menggunakan arsitektur yang memisahkan logika dari pandangan Anda. Jika perlu, Anda harus menggunakan arsitektur yang menggunakan pengontrol (seperti MVC) jika ada logika yang diperlukan yang tidak selalu cocok dengan model (seperti, misalnya, potongan parsing URL lintasan traversal pohon).

Berasal dari CI dan Yii, saya pikir memiliki pengontrol khusus adalah ide yang sangat keren. Namun, ketika mengembangkan aplikasi dengan antarmuka RESTful yang tepat, maka kebutuhan untuk kontroler untuk menangani logika non-model-spesifik tampaknya berkurang. Jadi, ketika pindah ke Django dan kemudian Piramida (keduanya tidak mengikuti arsitektur MVC sepenuhnya), saya menemukan bahwa controller itu sebenarnya bukan komponen yang diperlukan untuk aplikasi yang saya bangun. Perhatikan bahwa kedua kerangka kerja memiliki fitur "controller'ish", seperti Pengiriman URL dalam Piramida, tetapi ini adalah hal konfigurasi, bukan hal runtime (seperti CController di Yii).

Pada akhirnya, yang benar - benar penting adalah pemisahan pandangan dari logika. Ini tidak hanya membersihkan hal-hal dalam hal implementasi, tetapi juga memungkinkan teknisi FE / BE bekerja secara paralel (ketika bekerja di lingkungan tim).

(Catatan: Saya tidak mengembangkan aplikasi web secara profesional, jadi mungkin ada sesuatu yang saya lewatkan)


Saya setuju sepenuhnya, jawaban yang bagus. Pengontrol tidak selalu diperlukan, itu hanya dimaksudkan sebagai strategi untuk pandangan untuk berkomunikasi dengan model.
Falcon

@ Falcon: Lihat, itu kebingungan saya. Saya telah melihat lebih dari satu orang mengatakan bahwa pandangan tidak boleh berbicara dengan pengontrol sama sekali; bahwa itu harus berbicara hanya dengan model ...
Billy ONeal

1
Jika Anda menggunakan implementasi MVC yang sebenarnya, tampilan tidak berbicara ke controller (atau model dalam hal ini). Pengontrol mengatur status model, menyiapkan data untuk tampilan dan mendorongnya ke tampilan.
Demian Brecht

@ Demian: Saya sudah mendengar kebalikannya (bahwa controller seharusnya tidak melakukan apa-apa secara efektif). Sering. Itulah masalah terbesar saya dengan pola ini; tampaknya tak seorang pun sepakat tentang apa itu.
Billy ONeal

3
Yap, saya sering mendengar bahwa jika Anda mendapatkan 10 programmer di sebuah ruangan, Anda akan mendapatkan 9 definisi berbeda tentang apa itu MVC. Sungguh, poin utama adalah pemisahan keprihatinan. Apa yang terjadi tampaknya menjadi perdebatan agama.
Demian Brecht

1

Ya, terminologi tentang ini berantakan. Sulit untuk dibicarakan karena Anda tidak pernah mengerti apa yang seseorang maksudkan dengan persyaratan.

Sejauh mengapa pengontrol terpisah, alasannya mungkin tergantung pada versi pengontrol yang Anda bicarakan.

Anda mungkin ingin pengontrol karena ketika Anda menjalankan tes tampilan memiliki banyak widget yang tidak Anda tulis dan mungkin tidak ingin menguji. Ya, Anda memisahkan implementasi dari warisan, sehingga Anda dapat menggunakan rintisan atau tiruan untuk menguji hal-hal lain, tetapi ketika Anda menguji tampilan konkret Anda sendiri itu lebih sulit. Jika Anda memiliki pengontrol yang tidak memiliki widget yang menjalankan kode yang sama maka Anda dapat mengujinya secara langsung, dan mungkin tidak perlu menguji widget melalui skrip.

Versi lain IMHO lebih sulit untuk menunjukkan manfaat konkret untuk. Saya pikir ini sebagian besar masalah pemisahan - pisahkan masalah GUI visual murni dari logika yang berlaku untuk GUI tetapi bukan bagian dari model bisnis (hal-hal seperti, terjemahkan pembaruan dari model di mana widget harus terlihat). Namun dalam praktiknya kedua kelas cenderung sangat erat digabungkan (bahkan jika mereka berkomunikasi melalui antarmuka) sehingga sulit untuk terlalu marah menggabungkan mereka menjadi hanya tampilan, dan hanya mengawasi cara-cara fungsionalitas mungkin lebih dapat digunakan kembali. jika mereka terpecah.


0

Sederhananya: pemisahan kekhawatiran. Selain semua pembicaraan tentang cara yang "benar" dalam melakukan sesuatu, memiliki kode yang lebih bersih, dll. Anda dapat mengatakan bahwa MVC memungkinkan Anda untuk lebih mudah menggunakan kembali kode Anda. Pada dasarnya Anda memprogram model dan pengontrol Anda dan Anda dapat menggunakannya secara tidak jelas di aplikasi web, aplikasi meja, layanan, di mana saja tanpa banyak usaha.


2
Itu tidak berbeda dengan hanya mendefinisikan lapisan UI dan lapisan fungsional. Anda belum menjelaskan mengapa bit controller diperlukan.
Billy ONeal

-3

Nah alasan dasar untuk menggunakan struktur MVC muncul dalam pengaturan industri, di mana proses kerja tunggal, model tunggal diikuti untuk pengembangan aplikasi apa pun. Jadi, dalam kasus, jika proyek beralih dari satu modul organisasi ke yang lain, akan jauh lebih mudah untuk memberikan pemahaman yang lebih baik tentang skenario kerja. Ini memasukkan kejelasan pekerjaan.
Meskipun Anda, sebagai individu akan memiliki pendekatan yang berbeda untuk aplikasi Anda, Anda ketika bekerja dengan cara yang dikombinasikan dengan rekanan, pertama-tama akan berdiskusi dan menggunakan model yang disepakati bersama oleh keduanya (Anda dan rekanan Anda). Dan dalam kasus seperti itu, itu memisahkan tanggung jawab yang diberikan kepada Anda dan rekan Anda masing-masing dengan margin yang berbeda.


-3

Saya pikir MVC digunakan hanya kata kunci oleh para ahli teori yang adalah manajer. Namun, setelah mengatakan itu, iterasi web saat ini dengan HTML5 lazim, desain responsif, dan mencoba untuk membuat satu baris pemrograman database yang akan bekerja di web dan pada iPhone cocok untuk ide-ide umum MVC. Teknologi web front-end benar-benar bergerak dengan kecepatan cahaya sekarang dengan Jquery, iterasi baru dari kontrol CSS, sedangkan sisi server bergerak dengan kecepatan siput.

Akhirnya, semua yang ada di server benar-benar hanya berupa layanan atau "applet" yang memompa data ke front-end dan tergantung pada jenis klien yang Anda miliki, data tersebut akan dikonsumsi dan ditampilkan secara berbeda. Dalam pengertian itu, MVC masuk akal.

Dalam hal ini, saya percaya pada dunia nyata saat ini, MVVM benar-benar "pola" yang lebih baik atau apa pun yang Anda ingin menyebutnya daripada controller karena controller selalu harus kembali ke model untuk mengubah tampilan dan ini lambat . Dalam pola MVVM, ViewModel dapat memberikan pembaruan langsung ke tampilan. Selain itu model MVVM mempromosikan prinsip desain RESTful IMHO.


apakah ini hanya pendapat Anda, atau Anda dapat mendukungnya entah bagaimana?
nyamuk

3
(tidak downvote) Yah, sudah menjadi kata kunci yang terjadi 40 + tahun sekarang jika ya.
Billy ONeal

2
Saya akan mendorong Anda untuk menaruh beberapa penelitian tambahan ke asal-usul pola MVC dan pola tambahan yang muncul seperti MVP dan MVVM. Ada lebih banyak sejarah pada polanya daripada buzzwordiness saat ini yang membuat Anda percaya.

1
Dari Model View Controller History : "MVC ditemukan di Xerox Parc pada tahun 70-an, rupanya oleh Trygve Reenskaug. Saya percaya penampilan publik pertamanya adalah di Smalltalk-80. Untuk waktu yang lama hampir tidak ada informasi publik tentang MVC, bahkan di Smalltalk -80 dokumentasi. Makalah signifikan pertama yang diterbitkan pada MVC adalah "Buku Masak untuk Menggunakan Paradigma Antarmuka Pengguna Model-View-Controller di Smalltalk -80", oleh Glenn Krasner dan Stephen Pope, yang diterbitkan dalam JournalOfObjectOrientedProgramming edisi Agustus / September 1988. (BERGABUNG). "

Ada banyak kata kunci yang jauh lebih penting seperti CIUMAN yang telah ada lebih lama dan mendapat banyak perhatian KURANG.
Michael Barber
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.