Apa kekurangan MVC? [Tutup]

Saya telah menggunakan MVC / MV * sejak saya mulai mengatur kode saya bertahun-tahun yang lalu. Saya sudah menggunakannya begitu lama sehingga saya bahkan tidak bisa memikirkan cara lain untuk menyusun kode saya dan setiap pekerjaan yang saya miliki setelah magang adalah berbasis MVC.

Pertanyaan saya adalah, apa saja jatuhnya MVC? Dalam kasus apa MVC akan menjadi pilihan yang buruk untuk suatu proyek dan apa yang akan menjadi (lebih) pilihan yang benar? Ketika saya mencari alternatif MVC, hampir setiap hasil hanyalah jenis MVC yang berbeda.

Untuk mempersempit ruang lingkup agar ini tidak ditutup, katakanlah untuk aplikasi web. Saya mengerjakan backend dan front-end untuk proyek yang berbeda, jadi saya tidak bisa mengatakan hanya front-end atau backend.

Anda harus selalu ingat - MVC adalah pola terkait UI. Jika Anda membuat aplikasi yang kompleks, Anda harus mengambil semuanya, yang tidak terkait dengan UI, dari MVC triplet ke kelas, subsistem, atau lapisan lain.

Itu adalah kesalahan terbesar saya. Saya menghabiskan waktu lama untuk memahami aturan sederhana itu:

• Jangan sebarkan pola MVC di antara seluruh aplikasi,
• Batasi hanya untuk hal-hal yang berhubungan dengan UI.

Selalu periksa apakah kode yang Anda tulis secara logis di tempat yang benar, artinya secara logis sesuai dengan tanggung jawab kelas tempat Anda meletakkannya. Jika tidak - pindahkan kode begitu Anda memahaminya.

Semua pola yang Anda sebut MVC-alternatif (yaitu Model-View-Presenter, Model-View-ViewModel) hanyalah cara menerapkan konsep MVC umum.

Menurut pendapat saya ada dua jenis MVC - murni dan tidak murni (karena tidak ada kata yang lebih baik :)

Pure MVC adalah apa yang diperkenalkan ke dalam obrolan ringan:

Ini dimaksudkan untuk aplikasi komputasi / desktop pribadi. Seperti yang Anda lihat, model menginformasikan pandangan tentang pembaruan / perubahan yang dibuat untuk itu. Tidak demikian halnya dengan (tidak murni) MVC.

MVC (tidak murni) lainnya yang disebut-sebut untuk aplikasi web lebih merupakan pola PAC ( Presentation-abstraction-control ) daripada MVC klasik di atas. Itu lebih dari organisasi kode dan pemisahan kekhawatiran:

• Model : Abstraksi untuk data yang disimpan
• Kontrol : Biasanya apa yang dikenal sebagai lapisan logika bisnis serta bagian dari aplikasi yang bertanggung jawab untuk merutekan permintaan HTTP ke logika bisnis yang sesuai (alias controller)
• Lihat : Sebagian besar melihat templat yang memformat data dari model dan mengembalikannya ke klien. Model TIDAK PERNAH mengirimkan pembaruan ke tampilan juga tampilan 'berlangganan' untuk pembaruan dari model. Ini akan menjadi mimpi buruk. Oleh karena itu lebih seperti PAC daripada MVC sejati.

Sekarang, inilah cara aplikasi web biasanya disusun:

1. Front-end : MVC pada klien menggunakan kerangka kerja seperti Backbone.js dll., Ini adalah bentuk MVC 'benar' pada dasarnya.
2. Back-end : Sekali lagi, Anda memiliki (tidak murni) MVC / PAC untuk organisasi kode dan pemisahan masalah
3. Aplikasi web global (untuk aplikasi web secara keseluruhan): Jika Anda memiliki backend TENANG yang hanya mengembalikan data JSON, maka seluruh backend Anda dapat dianggap sebagai model untuk aplikasi klien front-end di mana Lihat dan Pengontrol berada pada intinya.

Jadi apa saja kerugian dari MVC ? Nah, polanya telah teruji oleh waktu sehingga tidak banyak yang penting selain itu agak 'rumit'. Anda lihat, MVC adalah pola gabungan - menerapkan strategi / pola pengamat dan semuanya diatur dengan baik untuk membentuk pola tingkat tinggi.

Haruskah Anda menggunakannya di mana-mana? Mungkin tidak. Aplikasi web yang sangat kompleks mungkin terpecah menjadi beberapa lapisan! Anda mungkin tidak dapat pergi hanya dengan lapisan Lihat / Logika Bisnis / Data. Kerangka / organisasi menyeluruh mungkin masih berupa MVC-ish, tetapi hanya pada tingkat makroskopik.

Berikut adalah contoh di mana hanya MVC dengan sendirinya mungkin pilihan yang buruk : Cobalah merancang sistem kontrol lalu lintas udara atau aplikasi pemrosesan pinjaman / hipotek untuk bank besar - hanya MVC dengan sendirinya akan menjadi pilihan yang buruk. Anda pasti akan memiliki bus Acara / antrian pesan bersama dengan arsitektur berlapis-lapis dengan MVC di dalam lapisan-lapisan individual dan mungkin desain MVC / PAC yang menyeluruh untuk menjaga basis kode lebih terorganisir.

Kesalahan yang dibuat banyak orang dengan pola desain adalah melihatnya bekerja dengan indah di satu tempat dan kemudian mencoba menerapkannya di mana-mana.

Jika Anda telah bekerja di satu tempat untuk sementara waktu, Anda hampir dapat memberi tanggal sepotong kode dengan melihat teknologi / pola desain / praktik apa yang sedang populer saat itu, misalnya lajang / injeksi ketergantungan / TDD dll.

Adapun di mana tidak menggunakannya. Nah, di mana pun satu elemen triplet MVC tidak berlaku. Aplikasi konsol mungkin tidak mengimplementasikan antarmuka sama sekali. Program utilitas mungkin tidak memiliki model. Dan bisa dibilang, jika Anda tidak memiliki model atau tampilan, Anda tidak memerlukan controller.

Masalahnya jarang dengan konsep - lebih dengan implementasi. Tidak peduli seberapa bagus paradigma itu, luangkan waktu untuk melihat apakah itu cocok untuk masalah yang dihadapi.

MVC, seperti halnya paradigma apa pun yang tidak terpisahkan dengan platform pengembangan Anda, semakin rumit. Kelemahannya adalah Anda dapat membuat kelas terpisah yang tidak boleh dipisahkan, dan mengurangi kejelasan tentang bagaimana mereka terikat erat. (Atau, untuk proyek-proyek sepele, bahkan mengaburkan kode Anda.)

Alternatif untuk masalah pertama adalah memisahkan kode tersebut ke dalam sub proyek independen; alternatif untuk yang kedua adalah kode yang tidak dipisahkan, baik di kelas atau model file.

Pemahaman saya tentang penerapan MVC / MV * mengikuti prinsip Separation of Concerns (SoC) - memisahkan program / kode menjadi bagian / bagian yang berbeda sehingga setiap bagian dapat mengatasi masalah yang berbeda (Ref: http://en.wikipedia.org / wiki / Separation_of_concerns )

ada banyak manfaat ketika memisahkan masalah: satu tidak akan mempengaruhi yang lain dan pengembang dapat bekerja pada unit tanpa mempengaruhi sisanya, dll. & dll ... MVC bukan satu-satunya pola yang mengikuti SoC, pada dasarnya, OOP itu sendiri adalah konsep yang bagus untuk memecah hal menjadi unit.

MVC / MV * sangat berguna ketika Anda menangani pengembangan terkait UI, sementara di bawahnya mungkin ada lebih banyak pola - pabrik, singleton, fasad, dll. beberapa kasus. Anda mungkin melihat MVC banyak - itu karena banyak proyek memiliki elemen UI.

dengan demikian, Ketika berbicara tentang kelemahan MVC, itu benar-benar tergantung pada proyek yang Anda lakukan - apakah ada UI? apakah itu membutuhkan skalabilitas / ekstensibilitas yang hebat? apakah ada banyak interaksi antara UI dan sistem-belakang? misalnya, halaman web informasi sederhana tidak memerlukan MVC sama sekali, kecuali jika Anda berencana untuk memperluasnya ke halaman interaktif yang hebat di masa depan.

jadi untuk mengevaluasi MVC (atau lebih umum - pola desain), berikan konteks dan pikirkan tentang kompleksitas, skalabilitas, testablity, pemeliharaan, batasan waktu, dll. & dll.