Bagaimana memilih TIDAK menggunakan kerangka kerja (Caliburn.Micro, dll.) Dalam aplikasi MVVM yang diberikan?

28

Saya pernah memulai proyek MVVM / WPF, yang akhirnya dibangun dan digunakan, dan untuk itu saya mempelajari banyak kerangka kerja Caliburn.Micro MVVM. Faktanya adalah: Saya akhirnya tidak menggunakan Caliburn.Micro untuk itu, dan akhirnya menerapkan beberapa konsep MVVM sendiri (khususnya, hanya kelas ViewModelBasedan RoutedCommand).

Sekarang saya ditugaskan untuk proyek yang agak lebih besar di sepanjang baris yang sama: "Aplikasi Desktop Offline Offline Klien Tunggal Pengguna", jadi saya katakan, dan saya memutuskan untuk menggunakan Caliburn.Micro. Dan di situlah "masalah" saya dimulai.

Saya telah membaca di posting blog terkenal ini , yang judulnya mengatakan bahwa "Jika Anda menggunakan MVVM maka Anda memerlukan kerangka kerja", bahwa:

"Mencoba melakukan sesuatu seperti MVVM tanpa kerangka kerja adalah pekerjaan yang sangat besar. Banyak kode duplikat, menciptakan kembali roda, dan melatih kembali orang untuk berpikir secara berbeda .

Setidaknya dengan kerangka kerja Anda menghindari kode duplikat dan mudah-mudahan tidak perlu menemukan kembali roda - memungkinkan Anda untuk fokus melatih kembali orang. Bagian pelatihan ulang umumnya tidak dapat dihindari, tetapi suatu kerangka kerja menyediakan kode dan struktur pipa ledeng, membuat prosesnya lebih mudah. "

Saya akan setuju pada bacaan pertama tetapi pengalaman saya yang sebenarnya dengan Caliburn.Micro (CM) dalam aplikasi saya yang sebenarnya adalah cluelessness dan disorientasi. Artinya, kerangka kerja tidak membuat proses lebih mudah sama sekali, justru sebaliknya. Membaca contoh-contoh yang selalu berulang yang diberikan oleh Rob Eisenberg dalam dokumentasi informal (juga), dan mencoba untuk menyimpulkan pola penggunaan dari sampel yang disediakan berbelit-belit, dan hubungan kelas dan antarmuka yang tidak langsung, di mana hal-hal yang tampaknya dirancang untuk bekerja berdasarkan pada efek samping, tampaknya tidak mungkin secara manusiawi kecuali jika Anda adalah seorang jenius berpengalaman (maaf untuk kata-kata kasar, tapi saya kira Anda tahu apa yang saya maksud).

Belum lagi bahwa setiap skenario sepele di atas tampaknya melibatkan wadah IoC, yang merupakan sesuatu yang belum pernah saya kerjakan, dan yang sepertinya memecahkan masalah yang bahkan mungkin tidak saya miliki . Saya merasa tidak ingin menghabiskan lebih banyak jam proyek untuk mempelajari hal-hal itu alih-alih memikirkan masalah dan domain aplikasi saya. Saya hanya ingin pisang, tetapi CM memberi saya gorila (IoC) memegang sekeranjang pisang.

Sekarang saya sedang mempertimbangkan untuk pindah kembali ke kerangka MVVM tenunan saya - hanya terdiri dari beberapa kelas khusus MVVM yang sebenarnya ingin saya terapkan - saya ingin setidaknya memberi CM kesempatan, kalau-kalau saya kehilangan sesuatu di sini, atau sekadar melakukan hal-hal "dengan cara yang salah" karena kurangnya pengalaman dan ketidaktahuan. Dan pertanyaannya adalah:

Ada konsensus luas bahwa "kerangka kerja membuat segalanya lebih mudah dan lebih alami", tetapi jika saya mengalami hal yang sebaliknya, apakah ini berarti saya tidak boleh menggunakan kerangka kerja, atau bahwa saya mencoba mempelajarinya dengan cara yang salah? Apakah ada petunjuk bahwa saya seharusnya tidak menggunakan kerangka kerja sejak awal? Atau adakah cara "benar" untuk mengetahui cara menggunakan CM untuk pengembangan MVVM sederhana?

frameworks wpf mvvm

— heltonbiker
sumber

1

Secara pribadi saya memilih dan memilih item dari setiap kerangka kerja untuk digunakan untuk perilaku tertentu, dan saya mengabaikan sisanya. Sebagai contoh, saya suka menggunakan Microsoft PRISM untuk pengiriman EventAggregatorpesan, dan NotificationObjectuntuk ViewModelBase, dan MVVM Light RelayCommanduntuk perintah. Yang penting adalah mengidentifikasi masalah apa yang akan dipecahkan oleh kerangka kerja untuk Anda, dan hanya gunakan solusi itu. Jangan merasa Anda terpaksa menggunakan seluruh pustaka kerangka kerja.

— Rachel

@Rachel Saya berencana untuk menggunakan pendekatan ini dengan Caliburn.Micro, tetapi tidak dapat menemukan RelayCommandimplementasi (karena "mengikat" langsung ke metode dengan konvensi, alih-alih mengikat ke properti ICommand).

— heltonbiker

Saya tidak pernah menggunakan kerangka kerja Caliburn karena saya tidak suka seberapa dekat tampaknya mengikat Tampilan ke lapisan Model / ViewModel. Dalam kasus Anda, saya tidak melihat alasan mengapa Anda tidak dapat menggunakan RelayCommanddari perpustakaan lain jika yang digunakan oleh Caliburn Micro tidak bekerja untuk Anda.

— Rachel

@Rachel tentang "seberapa dekat [caliburn] mengikat tampilan ke lapisan MVM", apa maksudmu? Apa yang akan menjadi cara "non-kalibrasi" untuk mengikat lapisan-lapisan itu dengan cara yang lebih baik dan lebih MVVM? (Saya bertanya dengan tulus karena saat ini saya tidak tahu).

— heltonbiker

Jujur saya belum pernah menggunakan Caliburn Micro, jadi saya merasa saya adalah hakim yang buruk terhadap kerangka kerja. Saya ingat mendapatkan kesan bahwa View diciptakan pertama dan bertanggung jawab untuk memutuskan objek kode-belakang, yang merupakan salah satu aspek yang saya tidak suka karena saya tidak suka pengembangan View-First. Yang lain adalah binding otomatis yang bergantung pada bagaimana Anda memberi nama komponen XAML, karena saya pikir itu terlalu banyak mengikat UI ke lapisan bisnis. Saya telah mendengar hal-hal baik tentang kerangka kerja itu, dan tidak akan menyarankan menghindarinya hanya pada pendapat saya. Cobalah sendiri dan lihat apakah Anda suka :)

— Rachel

16

Saya telah mencoba CaliburnMicro dan MVVMLight dan ketika menggunakan Caliburn saya benar-benar merasakan apa yang Anda rasakan, tentu terasa sangat ajaib dapat mengikat kontrol ke properti hanya dengan menggunakan Name = "PropertyName" alih-alih Teks lama = "{Bind PropertyName}" tetapi di Akhirnya Caliburn pergi jauh ke laut untuk melakukan hal ajaib ini, ketika terjadi kesalahan, sangat sulit untuk melakukan debug, untuk memperburuk keadaan mereka memiliki banyak cara untuk melakukan satu hal.

Tetapi ketika menggunakan MVVMLight itu tipis, ketika Anda menggunakannya Anda mungkin menyadari bahwa itu hampir 100% seperti MVVM Framework Anda, dengan beberapa fitur ditaburkan di dalamnya.

Saya tahu ini tidak menjawab pertanyaan Anda "Bagaimana TIDAK menggunakan kerangka kerja" tapi terus terang saya tidak bisa merekomendasikan Anda untuk pergi rute itu karena itu hanya salah, saya juga berpikir Anda hanya kehilangan karena Anda menggunakan kerangka berfitur lengkap daripada menggunakan sederhana satu dulu.

— kirie
sumber

Jadi, menurut Anda, apakah saya setidaknya harus mencoba menggunakan MVVMLight sebagai semacam "obat" dari "disorientasi Caliburn.Micro"? Saya pasti akan memeriksanya jika itu masalahnya.

— heltonbiker

@heltonbiker Pasti, cobalah. Itu jauh lebih sederhana setidaknya harus memberi Anda pijakan yang baik pada MVVM Framework.

— kirie

Saya setuju ada terlalu banyak keajaiban yang terjadi. Berasal dari latar belakang ac dan assembly saya kira. E sesuatu tidak akan berfungsi hanya untuk menemukannya karena sihir di latar belakang. Tidak mungkin melakukan debug dan ketika Anda memiliki masalah kinerja seringkali tidak banyak yang dapat Anda lakukan dengan mudah.

— bergulung

10

Penting untuk menyadari apa itu MVVM. Ini bukan sedikit fungsionalitas bersama yang tidak harus Anda laksanakan ulang (mem-parsing file JPEG atau menyambung ke server database SQL yang diberikan), ini adalah pola - sebuah pola untuk bagaimana seseorang dapat memilih untuk mengimplementasikan GUI yang kaya. Jadi, jika implementasi pola Anda sederhana dan mudah, saya pikir Anda tidak perlu merasa malu dalam menggunakannya daripada kerangka kerja.

Memang, saya percaya gagasan pola-sebagai-kerangka kerja telah terlalu jauh. Agar segala sesuatu menjadi suatu pola, itu harus menjadi bentuk umum dari suatu kelas solusi. Karena memang demikian, diharapkan pola perlu disesuaikan dengan sistem yang menggunakannya dan Anda tidak dapat melakukannya jika Anda mencoba menggunakan pola satu ukuran untuk semua. Akan jauh lebih konstruktif untuk menyerahkan implementasi pola kepada perancang aplikasi dan menyediakan perpustakaan yang merangkum fungsionalitas, daripada arsitektur.

— Michael
sumber

2

Ditambah lagi, MVVM seperti yang ditawarkan oleh Microsoft (out of the box, WPF) sangat kurang. Sangat membuat frustasi bahkan untuk programmer yang menganggap diri mereka (dan memang begitu) sebagai pengembang berpengalaman. String ajaib, pengecualian yang tidak jelas dalam runtime, sebagian besar hal mendasar seperti mengikat sekelompok radiobuttons ke enum terlihat seperti stackoverflow.com/q/397556/168719 - apa yang bisa dilakukan kerangka kerja? Mereka harus menggaungkan tingkat kerumitan ini, atau mencoba memberikan abstraksi yang sangat kental tentang hal itu

— Konrad Morawski

2

@KonradMorawski WPF dengan sendirinya bukan MVVM; Anda dapat melakukan kode di belakang dengan WPF, tapi itu bukan MVVM. Jadi jika Anda ingin melakukan WPF dan MVVM, Anda harus menggunakan kerangka kerja MVVM atau mengimplementasikannya sendiri.

— Andy

1

@Andy tentu saja, tetapi aman untuk mengatakan bahwa WPF ditujukan untuk MMVM. Saya mengacu pada fungsionalitas MVVM yang disertakan dengan WPF. Saya tahu Anda masih dapat melakukan kode di belakang

— Konrad Morawski

@KonradMorawski Anda dapat menggunakan WPF dengan MVVM, dan mereka membangunnya dengan mempertimbangkan hal itu dengan percaya, tetapi tidak ada fungsionalitas khusus MVVM yang dibangun ke dalam WPF. Sama seperti Anda dapat menggunakan MVP dengan WinForms, tetapi WinForms tidak menawarkan apa pun khusus untuk menggunakan pola itu, terserah Anda.

— Andy

3

@Andy mungkin kita berdebat tentang definisi sekarang. Yang saya maksudkan adalah bahwa semua "lem" yang memungkinkan MVVM sudah ada di sana - pengikatan data di XAML, DataContextdll.

— Konrad Morawski

7

Pengalaman pertama saya dengan WPF telah menggunakan Caliburn.Micro jadi ini mungkin sangat berbeda dari kebanyakan pengembang. Saya telah menemukan keduanya WPF dan Caliburn.Micro menjadi kurva belajar yang cukup curam, berasal dari WinForms, namun setelah beberapa pengalaman dengan keduanya saya menemukan mereka senang digunakan sebagai pasangan. Saat ini bekerja di organisasi yang berbeda di mana Caliburn.Micro tidak digunakan, saya menemukan bahwa ada BANYAK kode pipa duplikat yang membuat basis kode cukup besar dan rumit.

Saya benar-benar setuju bahwa ada beberapa gotchas dengan Caliburn.Micro, yang dapat menyulitkan debugging, namun begitu berpengalaman mereka lebih kecil kemungkinannya akan menyebalkan lagi. Peningkatan kecepatan pengembangan, kode yang lebih bersih dan lebih ramping serta kerangka keseluruhan yang mendorong MVVM yang lebih baik lebih dari cukup untuk saya.

Caliburn.Micro juga tidak membatalkan stok WPF - itu hanya dibangun di atasnya, yang berarti bahwa Anda masih dapat menggunakan fitur WPF jika Anda suka dan menggunakan Caliburn untuk beberapa bagian jika Anda suka. Ini mirip dengan bagaimana TypeScript dan JavaScript hidup berdampingan dalam pikiran saya.

Saya pasti akan menggunakan Caliburn.Micro dalam proyek WPF baru yang saya kerjakan di masa depan jika diberi kesempatan.

— Ross
sumber

3

Terima kasih atas jawaban anda. Dua tahun kemudian, saya menemukan lebih mudah untuk "menerima" kerangka kerja ini setelah memahami konsep Dependency Injection Containers, yang saya pelajari dari buku "DI in .NET" Mark Seeman yang sangat bagus.

— heltonbiker

1

Bagi siapa pun yang datang ke sini karena frustrasi dengan Caliburn.Micro, lihat kerangka kerja ini: Stylet

Ini terinspirasi oleh Caliburn.Micro, kecuali itu menghilangkan banyak keajaiban yang membuat Anda bingung tentang apa yang terjadi. Selain itu, dokumentasi ditulis dalam banyak bahasa yang lebih jelas tanpa mengasumsikan Anda ingin mengarungi jargon teknis. Jauh lebih baik untuk pemula.

Juga, Stylet mengambil pendekatan ViewModel-First. Caliburn.Micro dan banyak kerangka kerja lainnya menggunakan pendekatan Tampilan-Pertama, yang dilengkapi dengan beberapa masalah canggung. Jika Anda sudah sangat bagus dalam prinsip-prinsip SOLID dan kode berpola, Anda cenderung menemukan pendekatan ViewModel-First yang lebih alami karena dibutuhkan perspektif bahwa logika Anda harus menggerakkan sistem - bukan tampilan.

— JamesHoux
sumber