Apakah Model-View-Controller mati di bagian depan?

Semakin banyak pengembang front-end yang mengadopsi arsitektur searah. Jadi apa masa depan untuk pendekatan Model-View-Controller (MVC) klasik?

Untuk memahami bagaimana kita sampai pada titik ini, pertama-tama mari kita tinjau evolusi arsitektur front-end.

Selama empat tahun terakhir, saya telah mengerjakan banyak proyek web dan menghabiskan banyak waktu untuk merancang bagian depan dan mengintegrasikan kerangka kerja ke dalamnya.

Sebelum 2010, JavaScript - bahasa pemrograman jQuery ditulis - digunakan sebagian besar untuk menambahkan manipulasi DOM ke situs web tradisional. Pengembang tampaknya tidak terlalu peduli dengan arsitektur itu sendiri. Hal-hal seperti pola modul pengungkapan cukup baik untuk menyusun basis kode kami.

Diskusi kita saat ini tentang arsitektur front-end vs back-end baru muncul pada akhir 2010. Ini adalah saat para pengembang mulai mengambil konsep aplikasi satu halaman dengan serius. Ini juga ketika kerangka kerja seperti Backbone dan Knockout mulai menjadi populer.

Karena banyak dari prinsip kerangka kerja ini dibangun cukup baru pada saat itu, desainer mereka harus mencari inspirasi di tempat lain. Mereka meminjam praktik yang sudah mapan untuk arsitektur sisi server. Dan pada saat itu, semua kerangka kerja sisi server yang populer melibatkan semacam implementasi model MVC klasik (juga dikenal sebagai MV * karena variasinya).

Ketika React.js pertama kali diperkenalkan sebagai pustaka rendering, banyak pengembang mengejeknya karena mereka menganggap caranya menangani HTML di JavaScript sebagai kontra-intuitif. Tetapi mereka mengabaikan kontribusi terpenting yang dibawa oleh React ke dalam tabel - Arsitektur Berbasis Komponen .

React tidak menciptakan komponen, tetapi membawa ide ini selangkah lebih maju.

Terobosan besar dalam arsitektur ini diabaikan bahkan oleh Facebook, ketika mereka mengiklankan React sebagai "V di MVC".

Di samping catatan, saya masih mengalami mimpi buruk setelah meninjau basis kode yang membuat Angular 1.x dan React bekerja bersama.

2015 membawa kami perubahan besar dalam pola pikir - dari pola MVC yang sudah dikenal ke Arsitektur Searah dan Aliran Data yang berasal dari Flux dan Pemrograman Reaktif Fungsional, didukung oleh alat seperti Redux atau RxJS.

Jadi di mana semuanya salah untuk MVC?

MVC mungkin masih merupakan cara terbaik untuk menangani sisi server. Kerangka kerja seperti Rails dan Django menyenangkan untuk dikerjakan.

Masalahnya berasal dari fakta bahwa prinsip dan pemisahan yang diperkenalkan MVC di server tidak sama dengan yang ada di klien.

Kopling Tampilan Pengontrol

Di bawah ini adalah diagram bagaimana View dan Controller berinteraksi di server. Hanya ada dua titik kontak di antara mereka, keduanya melintasi batas antara klien dan server.

Saat Anda pindah ke MVC di klien, ada masalah. Pengontrol mirip dengan apa yang kami sebut "di belakang kode". Kontroler sangat bergantung pada View. Dalam kebanyakan implementasi framework, ini bahkan dibuat oleh View (seperti halnya dengan, misalnya, ng-controller di Angular).

Selain itu, jika Anda memikirkan Prinsip Tanggung Jawab Tunggal, ini jelas melanggar aturan. Kode pengontrol klien berurusan dengan penanganan peristiwa dan logika bisnis , pada tingkat tertentu.

Model Gemuk

Pikirkan sedikit tentang jenis data yang Anda simpan dalam Model di sisi klien.

Di satu sisi, Anda memiliki data seperti pengguna dan produk , yang mewakili Status Aplikasi Anda . Di sisi lain, Anda perlu menyimpan Status UI - hal-hal seperti showTab atau selectedValue .

Mirip dengan Pengontrol, Model ini melanggar Prinsip Tanggung Jawab Tunggal, karena Anda tidak memiliki cara terpisah untuk mengelola Status UI dan Status Aplikasi .

Jadi, di mana komponen cocok dengan model ini?

Komponennya adalah: Tampilan + Penanganan Peristiwa + Status UI .

Diagram di bawah menunjukkan bagaimana Anda sebenarnya membagi model MVC asli untuk mendapatkan komponen. Apa yang tertinggal di atas garis adalah apa yang Flux coba pecahkan: mengelola Status Aplikasi dan Logika Bisnis .

Dengan popularitas React dan arsitektur berbasis komponen , kami melihat munculnya arsitektur searah untuk mengelola status aplikasi.

Salah satu alasan mengapa keduanya berjalan begitu baik adalah karena mereka menutupi pendekatan MVC klasik sepenuhnya. Mereka juga memberikan pemisahan perhatian yang jauh lebih baik dalam hal membangun arsitektur front-end.

Tapi ini bukan lagi cerita React. Jika Anda melihat Angular 2, Anda akan melihat pola yang sama persis sedang diterapkan, meskipun Anda memiliki opsi berbeda untuk mengelola status aplikasi seperti ngrx / store.

Tidak ada yang bisa dilakukan MVC lebih baik pada klien. Itu ditakdirkan untuk gagal sejak awal. Kami hanya butuh waktu untuk melihat ini. Melalui proses lima tahun ini, arsitektur front-end berkembang menjadi seperti sekarang ini. Dan jika Anda memikirkannya, lima tahun bukanlah waktu yang lama untuk praktik terbaik muncul.

MVC diperlukan pada awalnya karena aplikasi front end kami semakin besar dan kompleks, dan kami tidak tahu bagaimana menyusunnya. Saya pikir itu memenuhi tujuannya, sambil juga memberikan pelajaran yang baik tentang mengambil praktik yang baik dari satu konteks (server) dan menerapkannya ke yang lain (klien).

Jadi bagaimana masa depan?

Saya tidak berpikir bahwa kami akan kembali ke arsitektur MVC klasik dalam waktu dekat untuk aplikasi front end kami.

Karena semakin banyak pengembang mulai melihat keuntungan dari komponen dan arsitektur searah, fokusnya adalah membangun alat dan pustaka yang lebih baik yang mengikuti jalur itu.

Akankah arsitektur semacam ini menjadi solusi terbaik lima tahun dari sekarang? Ada kemungkinan besar hal itu terjadi, tetapi sekali lagi, tidak ada yang pasti.

Lima tahun lalu, tidak ada yang bisa meramalkan bagaimana kita akan menulis aplikasi hari ini. Jadi saya rasa tidak aman untuk memasang taruhan untuk masa depan sekarang.

Itu saja! Saya harap Anda menikmati membaca ini. Saya menyambut umpan balik Anda di bawah ini.

Jika Anda menyukai artikelnya, klik hati hijau di bawah dan saya akan tahu upaya saya tidak sia-sia.