Sepertinya Anda telah jatuh ke dalam beberapa perangkap umum, tetapi jangan khawatir, mereka dapat diperbaiki :)
Pertama, Anda perlu melihat aplikasi Anda sedikit berbeda dan mulai memecahnya menjadi potongan-potongan. Kita bisa membagi bongkahan menjadi dua arah. Pertama kita dapat memisahkan logika kontrol (Aturan bisnis, kode akses data, kode hak pengguna, semua hal semacam itu) dari kode UI. Kedua kita dapat memecah kode UI menjadi beberapa bagian.
Jadi kita akan melakukan bagian terakhir terlebih dahulu, memecah UI menjadi beberapa bagian. Cara termudah untuk melakukan ini adalah memiliki bentuk host tunggal di mana Anda menulis UI Anda dengan kontrol pengguna. Setiap kontrol pengguna akan bertanggung jawab atas suatu wilayah formulir. Jadi bayangkan aplikasi Anda memiliki daftar pengguna, dan ketika Anda mengklik pengguna kotak teks di bawahnya diisi dengan rincian mereka. Anda bisa memiliki satu kontrol pengguna yang mengelola tampilan daftar pengguna dan yang kedua mengelola tampilan detail pengguna.
Trik sebenarnya di sini adalah bagaimana Anda mengelola komunikasi antara kontrol. Anda tidak ingin 30 kontrol pengguna pada formulir semua memegang referensi secara acak satu sama lain dan memanggil metode pada mereka.
Jadi, Anda membuat antarmuka untuk setiap kontrol. Antarmuka berisi operasi kontrol akan menerima dan setiap peristiwa yang ditimbulkannya. Ketika Anda berpikir tentang aplikasi ini, Anda tidak peduli apakah pemilihan daftar kotak daftar berubah, Anda tertarik pada kenyataan bahwa pengguna baru telah berubah.
Jadi menggunakan aplikasi contoh kami, antarmuka pertama untuk kontrol yang menjadi tuan rumah kotak daftar pengguna akan mencakup acara yang disebut UserChanged yang melewatkan objek pengguna.
Ini bagus karena sekarang jika Anda bosan dengan listbox dan ingin kontrol mata ajaib zoomy 3d, Anda cukup kode ke antarmuka yang sama dan pasang :)
Ok, jadi bagian kedua, memisahkan logika UI dari logika domain. Nah, ini jalan yang sudah usang dan saya sarankan Anda melihat pola MVP di sini. Sangat sederhana.
Setiap kontrol sekarang disebut Tampilan (V dalam MVP) dan kami telah membahas sebagian besar dari apa yang diperlukan di atas. Dalam hal ini, kontrol dan antarmuka untuk itu.
Yang kami tambahkan hanyalah model dan presenternya.
Model ini berisi logika yang mengelola status aplikasi Anda. Anda tahu hal-hal, itu akan pergi ke database untuk mendapatkan pengguna, menulis ke database ketika Anda menambahkan pengguna, dan seterusnya. Idenya adalah Anda dapat menguji semua ini dalam isolasi lengkap dari yang lainnya.
Presenter sedikit lebih sulit untuk dijelaskan. Ini adalah kelas yang terletak di antara model dan View. Ini dibuat oleh view dan view masuk sendiri ke presenter menggunakan antarmuka yang telah kita bahas sebelumnya.
Presenter tidak harus memiliki antarmuka sendiri, tetapi saya tetap ingin membuatnya. Jadikan apa yang Anda ingin presenter lakukan secara eksplisit.
Jadi presenter akan memaparkan metode seperti ListOfAllUsers yang View akan gunakan untuk mendapatkan daftar penggunanya, atau Anda bisa meletakkan metode AddUser dengan View dan memanggilnya dari presenter. Saya lebih suka yang terakhir. Dengan begitu presenter dapat menambahkan pengguna ke listbox kapan pun diinginkan.
Presenter juga akan memiliki properti seperti CanEditUser, yang akan mengembalikan true jika pengguna yang dipilih dapat diedit. View kemudian akan menanyakan bahwa setiap kali perlu tahu. Anda mungkin ingin yang dapat diedit dalam warna hitam dan hanya membaca yang berwarna abu-abu. Secara teknis itu adalah keputusan untuk Tampilan karena UI fokus, apakah pengguna dapat diedit di tempat pertama adalah untuk Presenter. Presenter tahu karena berbicara dengan Model.
Jadi secara ringkas, gunakan MVP. Microsoft menyediakan sesuatu yang disebut SCSF (Smart Client Software Factory) yang menggunakan MVP seperti yang saya jelaskan. Itu melakukan banyak hal lain juga. Ini cukup rumit dan saya tidak suka cara mereka melakukan semuanya, tetapi mungkin bisa membantu.