Pendekatan Pengembangan: Antarmuka Pengguna Masuk atau Model Domain Keluar?

Meskipun saya tidak pernah mengirim apa pun menggunakan Smalltalk, waktu singkat saya bermain dengannya pasti meninggalkan bekas. Satu-satunya cara untuk menggambarkan pengalaman adalah MVC seperti yang seharusnya. Pada dasarnya, semua pekerjaan berat untuk aplikasi Anda dilakukan di objek bisnis (atau model domain jika Anda cenderung). Kontrol standar terikat dengan objek bisnis dalam beberapa cara. Misalnya, kotak teks dipetakan ke bidang objek (bidang itu sendiri adalah objek sehingga mudah dilakukan). Sebuah tombol akan dipetakan ke suatu metode. Ini semua dilakukan dengan API yang sangat sederhana dan alami. Kita tidak harus berpikir tentang mengikat objek, dll. Itu hanya berfungsi.

Namun, dalam banyak bahasa dan API yang lebih baru Anda dipaksa untuk berpikir dari luar masuk. Pertama dengan C ++ dan MFC, dan sekarang dengan C # dan WPF, Microsoft membuat dunia pengembangnya terhubung dengan pembuat GUI tempat Anda membangun aplikasi dengan mengimplementasikan pengendali acara. . Pengembangan Java Swing tidak begitu berbeda, hanya Anda yang menulis kode untuk membuat instantiate kontrol pada formulir sendiri. Untuk beberapa proyek, mungkin tidak pernah ada model domain - hanya penangan acara. Saya telah berada di dalam dan sekitar model ini untuk sebagian besar karier saya.

Setiap cara memaksa Anda untuk berpikir secara berbeda. Dengan pendekatan Smalltalk, domain Anda cerdas sementara GUI Anda bodoh. Dengan pendekatan VisualStudio default, GUI Anda cerdas sementara model domain Anda (jika ada) agak anemia.

Banyak pengembang yang bekerja dengan saya melihat nilai dalam pendekatan Smalltalk, dan mencoba menyemprotkan pendekatan itu ke dalam lingkungan VisualStudio. WPF memiliki beberapa fitur pengikat dinamis yang memungkinkan; tetapi ada batasannya. Tak pelak beberapa kode yang termasuk dalam model domain berakhir di kelas GUI.

Jadi, ke arah mana Anda mendesain / mengembangkan kode Anda? Mengapa?

• GUI dulu. Interaksi pengguna adalah yang terpenting.
• Domain dulu. Saya perlu memastikan sistemnya benar sebelum kita menempatkan UI di atasnya.

Ada pro dan kontra untuk kedua pendekatan tersebut. Model domain cocok di sana dengan katedral kristal dan pai di langit. GUI cocok di sana dengan cepat dan kotor (terkadang sangat kotor).

Dan untuk bonus tambahan: Bagaimana Anda memastikan kode dapat dipertahankan?

Tidak juga

Selama bertahun-tahun saya telah mengembangkan perangkat lunak saya mendapati diri saya berlatih metodologi kedua pertama karena selalu ada "jalan tengah" untuk mempertimbangkan. Pasang antarmuka antara kode UI dan kode bisnis, dan buat kesepakatan tentang apa yang dibutuhkan UI saat ini dari domain.

Biarkan saya membuat gambar untuk memperjelas konsep ini:

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

Dengan begitu Anda dapat bekerja secara iteratif pada UI dan model domain secara terpisah jika jalan tengah memperjelas data apa yang dapat diterima UI.

Alasan saya melihat mengapa beberapa proyek menjadi tidak dapat dipelihara adalah karena antarmuka antara data dan presentasi telah tergesa-gesa atau tidak ada (dengan kode penanganan data langsung ada di ui). Saya telah melihat begitu banyak proyek di mana kode basis data berada di dalam kode formulir sehingga saya kehilangan kepercayaan terhadap kemanusiaan. Hanya beberapa proyek yang pernah saya lihat yang memiliki jalan tengah yang kaku ini yang mengembalikan kepercayaan.

Ini tidak benar-benar peduli dari mana ujung mana Anda mulai pertama ... yang penting adalah bahwa Anda punya bahwa pemisahan yang jelas kekhawatiran di tempat. Kontrak di tengah itu cukup banyak mendefinisikan aplikasi atau sistem yang ada. Pikirkan yang pertama sebelum pergi dari bawah ke atas atau dari atas ke bawah .

Domain dulu. Saya perlu memastikan sistemnya benar sebelum kita menempatkan UI di atasnya.

Tidak ada lagi yang bisa dibuat bekerja - kecuali dalam kasus sederhana.

Mulai dari UI sering mengarah ke perangkat lunak yang rapuh dan buggy yang mungkin terlihat menyenangkan, tetapi seringkali memiliki masalah serius dalam model.

Ini bukan mengingat bahwa UI pertama ditakdirkan untuk gagal - jika modelnya cukup sederhana maka UI dapat dibangun terlebih dahulu dengan keyakinan bahwa model akan bekerja dengan baik pada akhirnya.

Dalam setiap kasus di mana model tidak dapat dengan mudah dibayangkan, itu harus dibangun terlebih dahulu.

Kasus terburuk adalah ketika beberapa programmer berpikir mereka dapat membayangkan model. Mereka mungkin telah menghilangkan detail penting, kasus khusus, pengecualian, atau pertimbangan kinerja. Karena GUI sudah dibangun, dan banyak pertimbangan di mana dihilangkan, modelnya mengerikan.

Ini sangat tergantung pada aplikasi yang ada.

Jika Anda sedang membangun aplikasi klien / server tertutup maka pendekatan apa pun sudah cukup; karena Anda akan memanipulasi ujung belakang agar sesuai dengan kebutuhan ujung depan pasti.

Jika Anda sedang membangun aplikasi klien / server terbuka di mana layanan web potensial akan diekspos untuk digunakan oleh pelanggan Anda, maka waspada tentang bagaimana layanan itu dapat digunakan oleh pelanggan untuk mengembangkan ujung depan sangat penting.

Sering kali akhir-akhir ini berkaitan dengan dorongan siklus berulang kecil dalam pengembangan (Scrum, Kanban, dll ...) ujung depan dan ujung belakang dilakukan secara paralel. Ini tentang menyediakan apa yang Anda butuhkan untuk iterasi yang diberikan; mengabaikan build jika kita membutuhkannya pendekatan . Dalam pendekatan paralel kedua ujung tetap lebih dekat sepanjang pengembangan yang dapat mengurangi kebutuhan untuk perubahan terus menerus ketika ujung depan dan ujung belakang bergabung. Ini adalah pendekatan yang saya sukai jika layak.

Anda menyebutkan ...

... WPF memiliki beberapa fitur pengikat dinamis yang memungkinkan; tetapi ada batasannya. Tidak dapat dihindari beberapa kode yang termasuk dalam model domain berakhir di kelas GUI ...

Tidak yakin apa yang Anda maksud dengan beberapa ? WPF dan SL keduanya terkenal karena fungsi pengikatannya. Tidak ada habisnya. Jika Anda dipaksa untuk menempatkan kode dalam View Anda dalam aplikasi WPF berbasis MVVM maka sesuatu perlu ditangani. Perilaku Terlampir adalah salah satu cara untuk menerapkan perilaku tanpa mengikat peristiwa dalam View, serta banyak pendekatan lain dalam memastikan View Anda tetap bersih.

Bagian depan dari posisi interaksi pengguna seharusnya tidak ada hubungannya dengan implementasi bagian belakang. Tugas ujung belakang satu-satunya ke ujung depan adalah menyediakan data melalui pemrosesan data atau cara lain. Ini mengikat kembali ke jenis aplikasi yang sedang dikembangkan.

Memastikan kode sumber dapat dipelihara adalah pertanyaan yang sepenuhnya berbeda dalam dirinya sendiri. Pada tingkat tinggi, ini berkaitan dengan praktik pengkodean terbaik bersama dengan pola, arsitektur, dan teknologi yang telah terbukti.

Saya lebih suka mendesain UI dasar terlebih dahulu (meskipun hanya di atas kertas), dengan masukan dari pelanggan. Pelanggan mungkin tidak benar-benar tahu apa yang mereka inginkan sampai mereka melihatnya. Anda tidak selalu bisa mempercayai apa yang dikatakan pelanggan kepada Anda. Anda bisa berinvestasi berminggu-minggu menulis model domain yang kuat hanya untuk mengetahui itu tidak sesuai dengan apa yang pelanggan inginkan setelah mereka mulai melihat prototipe UI.

Kami mencoba menggerakkan perangkat lunak kami dengan tes otomatis. Pengujian UI otomatis sangat memakan waktu. Script untuk memeriksa beberapa nilai pada konsol lebih mudah.

Dengan pemikiran itu, kami cukup berhati-hati untuk menjaga logika bisnis terpisah dari UI.

Saya ingat pernah ada pengembang utama yang berteriak kepada saya bahwa arsitektur Document / View dianggap usang ketika saya menyarankan agar kami berhenti mengikat semua kode bisnis kami dengan UI (dan kami menggunakan win32 di C ++ pada saat itu sehingga pemrograman drag & drop ini Hal itu bahkan bukan masalah kita). Saya hanya tercengang.

IMNSHO, tidak ada alasan untuk tidak memiliki setidaknya lapisan bisnis vs UI. Jika produk Anda melakukan sesuatu yang agak menarik, mutlak diperlukan pemisahan ini untuk memungkinkan penggunaan kembali kode.

Sebagai pengembang C #, saya pasti tidak berpikir Anda bingung untuk bekerja di luar-dalam. Saya lebih suka melakukan domain-model dulu, sebenarnya.

Untuk WPF, satu-satunya downside ke model yang saya jelaskan, adalah bahwa Anda kadang-kadang perlu memediasi antara UI Anda dan model domain Anda. Meski begitu, terkadang itu berarti lebih banyak pekerjaan, itu juga berarti kode yang lebih bersih.

Tentu, domain dulu!

Keindahan Smalltalk adalah Anda dapat dengan mudah "mengarahkan" model domain dengan berbagai cara, termasuk melakukan "mencetaknya" dari ruang kerja atau inspektur. Hanya ketika Anda yakin domain Anda berkinerja seperti yang diinginkan Anda berani fokus membangun GUI yang sempurna.

Itu bukan untuk mengatakan bahwa Smalltalkers tidak bekerja pada keduanya secara bersamaan, tetapi ketika GUI Anda gagal menerapkan logika bisnis, Anda umumnya memperbaiki model domain terlebih dahulu, daripada meletakkan kasus khusus di GUI Anda.