Nilai MVVM dalam Lini Aplikasi Bisnis (dan Kata-kata Praktik Pengembangan Saat Ini)


9

Setelah 2 tahun, saya masih berjuang dengan MVVM sebagai metode praktis untuk menghasilkan perangkat lunak yang berfungsi. Dalam beberapa kasus itu bagus. Saya melakukan aplikasi multithreaded yang mengendalikan jalur perakitan kecil yang akan menjadi baju tidur tanpa konsep MVVM. Abstraksi dari jalur perakitan fisik hampir tidak ada artinya.

Namun, karir saya sebagian besar berkisar pada jalur internal aplikasi bisnis - memformalkan dan mengoptimalkan operasi bisnis. Dalam aplikasi semacam itu, umumnya ada bisnis yang berputar di sekitar CRUD dan operasi gabungan. Dalam LOB, model tampilan saya menjadi koleksi yang sangat sederhana dari fungsi pembungkus satu baris dari metode kelas bisnis dan pada akhirnya hanya menyulitkan tugas-tugas paling sederhana seperti menunjukkan kotak pesan atau membuka jendela. Apakah tidak ada orang lain yang merasa aneh ketika orang-orang pergi ke discriptions panjang "injeksi ketergantungan" dan "penyedia pesan" untuk Window.ShowDialog panggilan yang telah ada selama beberapa dekade? Berapa banyak pertanyaan lain yang ada di stack overflow meminta saran untuk tugas-tugas yang sangat sederhana di winforms?

Jangan salah paham - Saya mendapatkan MVVM dan bagaimana itu bisa sangat berharga bagi tim besar yang melakukan pengembangan horizontal paket perangkat lunak yang dibungkus dan dipasarkan. Unit yang menguji model tampilan dapat menghemat jutaan dengan menghindari bug RTM yang buruk dan pengembang UI yang berdedikasi dapat memberikan pengalaman yang kaya. Tetapi ketika biaya pemindahan adalah minimal dan semua bisnis peduli untuk membayar adalah perangkat lunak kerja sederhana, mengapa saya harus menghabiskan waktu menguji unit "pembungkus" sederhana ketika logika bisnis saya sudah diuji unit? Berapa banyak waktu bisnis ini benar-benar akan memungkinkan saya untuk menghabiskan pada animasi lucu dan skema warna? Apakah ada yang tersisa untuk dilakukan oleh pengembang junior (melacak bug dalam fungsi penyimpanan yang digunakan untuk melihat "Save_Click",

Diakui, saya sangat suka penyatuan data WPF. Untuk memanfaatkannya, saya mengatur konteks data ke jendela itu sendiri, di mana ia memiliki akses ke kelas bisnis serta properti lainnya yang dapat diamati. Ya saya melanggar hampir setiap "aturan" MVVM dengan melakukannya. Tetapi setidaknya saya memiliki kode sederhana yang digerakkan oleh acara yang mudah dibaca DAN saya bisa memanfaatkan penyatuan data dan validasi baru. Masalahnya ada pada desainer - yang saya tidak gunakan terlalu banyak tetapi berharap sekarang lebih baik terintegrasi pada 2012 - desainer menunjukkan ratusan properti yang dimiliki oleh sebuah jendela dan kelas dasarnya.

Bagi mereka yang bisa berhubungan bisa Anda tunjukkan saya ke sumber daya, buku, atau bahkan hanya perubahan dalam perspektif yang membuatnya lebih mudah untuk menelan. Saya akan memberikan MVVM suntikan lain, tetapi terakhir kali saya merasa sangat bodoh karena khawatir tentang injeksi ketergantungan hanya untuk menunjukkan kotak pesan dari VM saya tidak punya niat pengujian unit. Bahkan jika saya melakukan pengujian unit, apakah kita benar-benar mendapatkan kualitas yang lebih baik dengan melakukan pengujian run time untuk kesalahan waktu kompilasi dari aplikasi yang "ditakuti secara ketat"?

Saya menyadari satu jawaban adalah hanya bertahan di winforms. Tetapi sebagai salah satu pendukung WebForms terakhir (saya memiliki banyak kritik yang sama tentang tren pengembangan web), saya merasa sedikit seperti dinosaurus seperti ketika saya menemukan kembali tidak ada lagi WebForms yang tersisa di jalur sertifikasi Microsoft. Bergerak maju adalah satu-satunya pilihan, bahkan jika saya tidak menyukainya.


1
Meskipun saya tidak mendorongnya, masih mungkin untuk menulis aplikasi WPF gaya WinForms dengan acara dan kode di belakang. Untuk aplikasi sekali saja, itu bukan masalah besar. Itu tergantung pada apa yang Anda hargai dan apa yang memberikan nilai bagi bisnis. Saya penggemar berat TDD dan MVVM, tetapi jika itu benar-benar tidak memberikan nilai, jangan lakukan itu. Itu bukan agama. Ingat saja bahwa kode sering hidup jauh lebih lama daripada yang kita pikirkan.
Matt H

"Apakah tidak ada orang lain yang merasa aneh ketika orang-orang pergi ke diskripsi panjang 'injeksi ketergantungan' dan 'penyedia pesan' untuk Window. Show Dialog panggilan yang telah ada selama beberapa dekade?" Saya merasa menjengkelkan, tetapi tipe orang yang melakukan semua itu (dengan merugikan benar-benar menyelesaikan sesuatu) selalu menjadi bagian dari lapangan, dan, sayangnya, mungkin selalu akan begitu. Strategi terbaik adalah mengabaikan / mengalihkan perhatian mereka sebanyak mungkin.
user1172763

Jawaban:


10

Perspektif saya adalah dari pengalaman bertahun-tahun bekerja dengan Winforms, "cara kuno," dengan acara dan kode-belakang. Jadi saya dapat memberi tahu Anda dengan pasti bahwa, setelah Anda melampaui aplikasi yang paling sederhana, kode Anda dengan cepat menjadi bola lumpur yang besar . Itu tidak bisa dihindari, karena itulah cara aplikasi ditulis saat itu.

Bentuk web sama saja, kecuali bahwa ia melempar komplikasi tambahan menjadi abstraksi stateful atas sistem stateless (web). Seperti yang dikatakan Rob Conery:

WebForms adalah dusta. Ini abstraksi yang dibungkus dalam penipuan yang ditutupi dengan saus berbaring yang disajikan di atas piring penuh pengalihan dan sulap. Tidak ada yang Anda lakukan dengan Webforms yang ada hubungannya dengan web - Anda membiarkannya bekerja untuk Anda.

Ini, dari orang yang menulis mapper-relasional objek-berfungsi penuh menggunakan dynamickata kunci dalam C # dan hanya empat ratus baris kode. Ketika dia berbicara secara otoritatif tentang sesuatu, saya mendengarkan.

Aplikasi yang sedang saya kerjakan adalah aplikasi Winforms, dengan beberapa tab dalam bentuk utama. Saya dapat secara dinamis memuat formulir ke masing-masing tab. Meskipun saya tidak mengikuti MVVM atau MVP (Anda bisa, dengan perpustakaan seperti ini ), saya secara agresif mendorong setiap bit kode yang saya bisa ke majelis terpisah, hanya menyisakan kode yang benar-benar diperlukan untuk menjalankan formulir. Masih ada beberapa ratus baris kode di sana, tidak termasuk kelas parsial yang mengandung definisi kontrol formulir, properti dan penugasan event handler, tetapi saya tidak harus menyentuhnya lagi, kecuali saya perlu menambahkan sesuatu yang baru ke formulir.

Saya memiliki metode statis yang bisa saya berikan formulir dan koleksi pasangan Key / Value, dan itu akan (menggunakan Refleksi) secara otomatis mencocokkan kunci ke bidang dalam formulir, dan mengisi formulir dengan nilai-nilai koleksi. Saya juga bisa melakukan sebaliknya, mendapatkan koleksi pasangan Key / Value dari bidang formulir. Semuanya itu sekitar dua puluh baris kode, tetapi membayar untuk dirinya sendiri setiap kali saya menggunakannya, karena saya tidak perlu menulis empat puluh pernyataan tugas kustom untuk empat puluh kontrol pada formulir.

Saya bisa mengambil daftar Kunci / Nilai, dan membuat serial ke XML, memungkinkan saya untuk bertahan ke file. Saya memiliki formulir lain yang dapat saya berikan DTO konvensional , dan memetakan bidangnya ke formulir. Tidak satu pun dari ini akan praktis dalam gaya "bola besar lumpur" dari Winforms. Hampir sepele ketika decoupling yang memadai digunakan.

Apakah semua ini terdengar familier? Itu harus; itu pada dasarnya bentuk pengikatan data orang miskin.

Diakui, saya sangat suka penyatuan data WPF. Untuk memanfaatkannya, saya mengatur konteks data ke jendela itu sendiri, di mana ia memiliki akses ke kelas bisnis serta properti lainnya yang dapat diamati.

Bagus untukmu. Itu tidak harus sesuai dengan MVVM. Tapi ingat, pola seperti MVVM diciptakan untuk membantu pengembang membangun sistem besar. Jika Anda hanya perlu menampilkan dialog, Anda mungkin tidak perlu semua saluran air itu.

Bagian dari kerumitan sistem seperti WPF melekat pada semua pustaka programmer yang berupaya memecahkan masalah tertentu dengan cara yang digeneralisasi. Untuk melakukan itu, Anda harus memperhitungkan setiap cara praktis yang mungkin digunakan seorang programmer menggunakan perpustakaan Anda. Itu menambah kompleksitas, tetapi bagi mereka yang merancang perpustakaan mereka dengan baik, itu juga membawa ke meja filosofi melakukan sesuatu dengan cara yang seragam dan konsisten.

Pertimbangkan perpustakaan jQuery John Resig: ini adalah esensi dari desain yang koheren, dan menyembunyikan banyak detail aneh tentang DOM , dan variasi dalam cara browser menanganinya. Apakah lebih sederhana hanya menulis beberapa baris Javascript? Terkadang. Tetapi manfaat menulis kode jQuery dalam API yang koheren dan seragam memudahkan orang berikutnya yang datang untuk memahami apa yang Anda lakukan, dan mempertahankan kode itu jika diperlukan.

Pengalaman nyata saya dengan model "aplikasi besar" adalah dalam menggunakan ASP.NET MVC. ASP.NET adalah untuk ASP.NET MVC karena Winforms adalah untuk WPF. Ketika saya bekerja di ASP.NET, saya selalu berjuang untuk menekuknya sesuai keinginan saya. ASP.NET MVC membungkuk kepada Anda. Ini adalah sukacita untuk digunakan; itu menghasilkan struktur sistem yang jelas dan terorganisir, dan memberi Anda kontrol penuh atas aplikasi dan markup Anda. Anda dapat menggunakan Javascript, jQuery dan CSS secara bebas, dan ASP.NET MVC tetap tidak digunakan.

Satu-satunya rintangan saya adalah membiasakan diri dengannya, dan mengenalinya dengan caranya sendiri.

Bacaan Lebih Lanjut
Anda Harus Belajar MVC oleh Rob Conery


Terima kasih atas tanggapan yang benar-benar bijaksana, bola lumpur yang besar - saya benar-benar merasakan hal itu pada zaman asp dan kode spageti klasik. 3 desain berjenjang dengan vb6 / mts memperbaiki banyak hal, dan kemudian. Net rilis menyatukan semuanya. Tetapi sekarang jika Anda merasakan pengembalian pola tambahan dengan cepat berkurang drastis - seperti menghabiskan $ 1 juta untuk mengambil 0,1 detik dari waktu seperempat mil Anda. "Saya secara agresif mendorong setiap bit kode yang saya bisa ke majelis terpisah" - tidakkah Anda menemukan bahwa ini memberikan pengalaman pengembangan yang luar biasa retak - terus-menerus melompat dari satu file ke file lain untuk membaca dua baris?
b_levitt

3
don't you find that this gives an incredibly fractured development experience - constantly jumping from file to file to read two lines?- Tidak, itu kebalikannya. Meletakkan di majelis lain seperti ini membebaskan pikiran Anda untuk fokus pada setiap kelas dan metode dengan persyaratannya sendiri, sebagai kotak hitam kecilnya sendiri. Itu sangat sulit dilakukan dengan bola lumpur yang besar. MVC beroperasi dengan prinsip yang sama: pengontrol tipis, model gemuk, tidak ada kode dalam tampilan kecuali benar-benar diperlukan.
Robert Harvey

3
Yagni hanya berlaku ketika Anda menulis kode sendiri. Jika Anda menulis perpustakaan umum yang harus memuaskan khalayak luas dengan beragam kebutuhan, Anda akan membutuhkannya.
Robert Harvey

1
Omong-omong, saya tidak menentang siklus hidup ASP.NET; Saya telah melihat orang menggunakannya untuk efek yang sangat baik. Saya hanya menemukan itu kontra-intuitif, itu saja. ASP.NET MVC tidak memaksa Anda untuk melakukan pengembangan sisi klien, jika Anda tidak mau; Anda dapat menggunakan tampilan "bodoh", dan itu berfungsi dengan baik. Perlu dicatat: banyak hal ini dapat dihasilkan kode (seperti bentuk Windows), jadi Anda tidak seperti menulis sendiri semua kodenya. Saya mengerti bahwa ini kurang benar dengan WPF, di mana Anda harus berurusan dengan XAML, dan saya pikir ada ruang untuk perbaikan di sana.
Robert Harvey

2
dozens of lines of plumbing to replace Window.Show- Itu sedikit penyederhanaan berlebihan. Jika jendela memerlukan data, selalu ada akan menjadi beberapa jenis pipa untuk mendapatkan data ke kontrol jendela, dan sebaliknya. Anda dapat menulis kode berulang itu berulang-ulang untuk setiap formulir yang Anda buat, atau menggunakan beberapa bentuk solusi umum seperti pengikatan data.
Robert Harvey
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.