Apakah praktik yang baik untuk menggunakan kontrol pengguna untuk menyusun formulir WPF bahkan jika kontrol pengguna ini hanya digunakan sekali?

Saya mengembangkan aplikasi WPF menggunakan MVVM dan saya belajar bagaimana melakukan hal-hal terbaik.

Saya memiliki formulir WPF dengan pemilih, dua daftar dengan bidang pencarian, dan beberapa elemen lainnya. Saat ini semua dalam satu bentuk dan berfungsi. Tetapi sekarang VM untuk formulir itu memiliki lebih dari 800 baris dan belum selesai.

Saya ingin menyusun formulir dan kode ini dengan lebih baik. Saya memikirkan daerah, file dengan kelas parsial dan kontrol pengguna. Saya pikir kontrol pengguna akan menjadi yang terbaik karena mereka merangkum beberapa kontrol dan logika. Jika saya akan menggunakan kontrol pengguna maka jumlah kode di jendela itu dan VM akan berkurang secara drastis.

Untuk melakukan ini dengan benar saya bekerja melalui buku "Pro WPF 4.5 In C # 4th Edition", Bab 18 - Elemen Kustom dan sampel ColorPickerUserControl. Sampel adalah tentang color picker dengan tiga slider dan memiliki 150 baris kode.

Saya rasa saya mengerti cara kerjanya tetapi menurut saya membuat kontrol pengguna, bahkan dengan fungsionalitas yang sangat terbatas seperti dalam sampel, adalah banyak pekerjaan . Jika saya akan menggunakan kontrol ini beberapa kali maka saya mengerti akan masuk akal untuk melakukan ini. Tetapi jika saya menggunakan kontrol hanya satu kali dan saya melakukan ini hanya untuk struktur formulir saya maka ini tampaknya banyak pekerjaan untuk mendapatkan sedikit keuntungan.

Pertanyaan saya adalah: Apakah praktik yang baik untuk menggunakan kontrol pengguna untuk struktur bentuk bahkan jika kontrol pengguna ini hanya digunakan sekali? Jika tidak, apakah ada alternatif yang lebih baik?

Sunting (tidak perlu membaca, hanya informasi lebih lanjut): Sampai sekarang saya tidak menulis rincian karena saya ingin belajar tentang prinsip tetapi setelah membaca 17 dari 26 jawaban yang menarik, berikut adalah beberapa perincian: Formulir ini untuk memilih judul musik.

• Grup A: (mungkin kontrol pengguna A) adalah tentang jenis pilihan seperti pilih berdasarkan artis atau album, dengan atau tanpa video, mungkin tahun publikasi, dll.

• Grup B: Daftar ini berisi nama artis yang difilter menurut kriteria di A. Pengguna dapat memfilter daftar yaitu hanya menampilkan nama artis yang mengandung "atas".

• Grup C: Daftar ini menunjukkan judul dari artis yang dipilih dalam B juga menggunakan kriteria dari A (yaitu audio atau video). Itu dapat disaring mirip dengan B yaitu hanya judul yang mengandung "Anda".

Sebagian besar logika terjadi di VM (DataContext dari formulir). Daftar dari A dan B berasal dari database. Daftar disaring dan disiapkan untuk presentasi (yaitu beberapa judul dengan nama yang sama tetapi dalam album yang berbeda). Pengguna memilih judul dalam Daftar-C dengan mengklik dua kali atau menggunakan seret dan lepas ke formulir WPF lainnya.

Yang saya inginkan: Saya ingin kode yang dapat dibaca sehingga saya dapat dengan mudah mengubahnya. Jika saya ingin menambahkan yaitu filter lain, katakan saja hanya menampilkan artis wanita maka akan lebih baik jika saya bisa pergi ke kontrol pengguna A dan menambahkan kotak centang untuk seniman pria dan / atau wanita.

XAML dalam bentuk saat ini tidak masalah, terstruktur dengan baik. Tetapi VM memiliki kode untuk semua hal di atas. Beberapa hal ada di konstruktor, beberapa di bagian perintah, beberapa properti dan bidang dukungan. Saya masih dapat menemukan hal-hal sekarang tetapi saya pikir akan lebih baik jika kode akan lebih terstruktur. Inilah mengapa saya berpikir tentang Kontrol Pengguna.

Saya mencoba mengikuti MVVM karena saya pikir logika di baliknya masuk akal. Tetapi saya bukan pengikut fanatik praktik teoretis apa pun. Yaitu jika saya bisa melakukan sesuatu dalam 5 baris CodeBehind atau dalam 50 baris di VM saya akan melakukannya di CodeBehind. Pertanyaan saya adalah tentang prinsip bagaimana membuat formulir terstruktur di WPF. Bentuk yang saya jelaskan di atas adalah contoh yang baik tetapi jawabannya tidak boleh berkonsentrasi pada yang satu ini dari tetapi pada gagasan bagaimana struktur formulir WPF yaitu dengan (atau tanpa) kontrol pengguna.

Tentang mengapa saya pikir kontrol pengguna banyak pekerjaan: Mereka memiliki properti ketergantungan, acara yang dirutekan, dll. Semua ini bagi saya jauh lebih rumit daripada properti "normal" dengan bidang dukungan dan INotify. Tapi mungkin saya hanya harus terbiasa dengan properti ketergantungan, acara yang dirutekan, dll.

Pastinya ya. Ini adalah ide yang baik dengan cara yang sama bahwa itu adalah ide yang baik untuk menerapkan pemisahan masalah pada kelas untuk menempatkan masing-masing dalam dirinya sendiri untuk melakukan satu tugas. Anda mungkin hanya memiliki satu instance dari kelas itu, tetapi itu tidak penting. Optimalisasi bukan dalam hal kinerja program tetapi dalam hal organisasi dan keseluruhan program "kesehatan".

Anda ingin dapat kembali ke program Anda satu hari dan tidak perlu menelusuri beberapa ratus halaman kode, bahkan jika itu dimasukkan ke dalam wilayah (menggunakan daerah pada kelas dengan banyak kode seperti meletakkan lipstik pada babi, oleh cara). Jika suatu hari Anda memutuskan untuk menggunakannya di tempat lain, Anda dapat melakukannya dengan anggun dan tanpa banyak masalah.

Hanya saja, jangan membuat godaan untuk memberikan akses kontrol pengguna ke formulir induk. Jika Anda melakukannya dengan cara ini, gunakan acara untuk menyampaikan informasi kepada orang tua, dengan formulir orang tua sebagai pelanggan.

Ini adalah pertanyaan yang sangat sulit dijawab tanpa melihat kode yang sebenarnya. Anda juga sedikit mencampur istilah. Kontrol pengguna bukan pemetaan 1: 1 dengan ViewModels.

Kontrol pengguna memiliki tujuan khusus dalam kehidupan: Kontrol ini adalah komposisi beberapa elemen UI yang digunakan sebagai satu kesatuan. Kontrol pengguna adalah subbagian dari Tampilan. Ini sangat berbeda dari ViewModel, yang berisi logika yang terikat dengan Tampilan.

Mungkin masuk akal untuk memecah XAML Anda menjadi beberapa kontrol pengguna semua didorong oleh ViewModel tunggal. Mungkin masuk akal untuk memecah kode XAML dan C # Anda menjadi beberapa pasang View-VM. Mungkin masuk akal untuk membiarkannya seperti yang Anda miliki sekarang. Mustahil untuk mengatakan tanpa melihat kode yang dimaksud.

Apa tujuan akhir Anda di sini? Apakah ukuran kode menyebabkan Anda benar-benar kesakitan atau hanya karena mengikuti praktik teoretis?

Apakah Anda mencoba mengurangi ukuran Tampilan XAML Anda atau ukuran C # ViewModels Anda? Ini adalah dua tugas yang sangat berbeda di dunia WPF MVVM.

800 baris tidak terlalu besar untuk VM yang mendukung UI yang memiliki kompleksitas. Memecah VM sering dapat menyebabkan lebih banyak masalah daripada memecahkannya. ViewModels membuat keputusan seperti "nonaktifkan fitur ini ketika daftar lain ini kosong". Mencoba untuk membagi pengambilan keputusan semacam itu di beberapa komponen sering kali tidak masuk akal dan hanya akan menambah kompleksitas kode.

Sekarang dengan mengatakan, mungkin ada pekerjaan yang Anda lakukan di VM yang tidak ada hubungannya dengan logika ViewModel Anda dan dapat dengan mudah dipartisi ke dalam kelasnya sendiri. Ini akan mengurangi ukuran ViewModel tanpa meningkatkan kompleksitas keseluruhan kode.

Saya kira itu hanya cara yang sangat panjang untuk mengatakan "Itu tergantung, dan kami tidak bisa mengatakannya tanpa melihat kode yang dimaksud".

Jika saya, yang tidak tahu apa-apa tentang aplikasi Anda, harus menambahkan bidang baru di atas bidang nama keluarga, atau mengubah urutan beberapa bidang ... Saya akan merasa mudah atau menakutkan?

Saya tidak percaya pada daerah karena kompiler tidak akan memeriksa apakah Anda salah menempatkan sesuatu di wilayah yang salah

Anda harus mengembangkan perangkat lunak dengan tujuan memudahkan orang untuk membangun apa yang Anda buat.