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.