Bagaimana saya bisa memisahkan antarmuka pengguna dari logika bisnis dengan tetap mempertahankan efisiensi?

Katakanlah saya ingin menunjukkan bentuk yang mewakili 10 objek berbeda di kotak kombo. Misalnya, saya ingin pengguna memilih satu hamburguer dari 10 yang berbeda yang mengandung tomat.

Karena saya ingin memisahkan UI dan logika, saya harus memberikan bentuk representasi string hamburger untuk menampilkannya di kotak kombo. Jika tidak, UI harus menggali ke dalam bidang objek. Kemudian pengguna akan memilih hamburguer dari kotak kombo, dan mengirimkannya kembali ke controller. Sekarang controller harus menemukan lagi kata hamburguer berdasarkan representasi string yang digunakan oleh form (mungkin ID?).

Bukankah itu sangat tidak efisien? Anda sudah memiliki objek yang ingin Anda pilih. Jika Anda mengirim ke formulir seluruh objek, dan lalu mengembalikan objek tertentu, Anda tidak perlu menolaknya nanti karena formulir sudah mengembalikan referensi ke objek itu.

Selain itu, jika saya salah dan Anda benar-benar harus mengirim seluruh objek ke formulir, bagaimana saya bisa mengisolasi UI dari logika?

^{Pertama-tama, contoh yang Anda berikan tidak terlalu tidak efisien; hanya sedikit tidak efisien; inefisiensinya berada di bawah tingkat yang dapat dilihat. Tapi, bagaimanapun, mari kita lanjutkan dengan pertanyaan.}

Cara saya memahaminya, ketika kita berbicara tentang pemisahan UI dan Logika , yang kita maksudkan adalah penghindaran erat .

Close coupling mengacu pada situasi di mana UI mengetahui (dan memanggil) logika, dan logika mengetahui (dan memanggil) UI. Untuk menghindari kopling tertutup, pengguna tidak perlu menghapus kopling sama sekali. (Itulah yang tampaknya ingin Anda tuju dengan menghancurkan antarmuka di antara mereka hingga ke antarmuka string yang paling umum-denominator.) Yang perlu dilakukan adalah menggunakan kopling longgar .

Kopling longgar berarti bahwa A tahu B, tetapi B tidak tahu A. Dengan kata lain, kedua pihak yang terlibat memainkan peran klien dan server yang berbeda, di mana klien mengetahui server, tetapi server tidak tahu klien.

Dalam hal UI dan logika, cara terbaik untuk mengatur ini menurut saya adalah dengan melihat logika sebagai server, dan UI sebagai klien. Jadi, UI dibangun untuk logika, memiliki pengetahuan tentang logika, dan memanggil logika, sementara logika tidak tahu apa-apa tentang UI, dan hanya menanggapi permintaan yang diterimanya. (Dan permintaan ini datang dari UI, tetapi logikanya tidak tahu itu.)

Untuk meletakkannya dalam istilah yang lebih praktis, tidak ada file kode sumber mana pun dari logika yang harus Anda temukan pernyataan include / import / using yang merujuk ke file UI, sedangkan file kode sumber UI akan penuh dengan include / import / using pernyataan yang merujuk ke file Logika.

Jadi, untuk kembali ke kasus Anda, sama sekali tidak ada yang salah dengan fakta bahwa kode UI yang mengisi kotak kombo tahu tentang kelas hamburger. Akan ada masalah jika kelas hamburger tahu apa-apa tentang kotak kombo.

Kebetulan, desain ini memungkinkan hal lain yang harus Anda harapkan dari sistem seperti itu: harus memungkinkan untuk menyambungkan sebanyak mungkin UI yang berbeda sesuai dengan logika, dan semuanya harus tetap berfungsi.

Anda harus memisahkan setiap bagian Model, View & Controller, tetapi tidak ada alasan mengapa Anda tidak dapat (misalnya) melewatkan objek Model antara Controller dan View.

Jadi dalam kasus Anda, Hamburgerobjek akan menjadi bagian dari Model. Anda kemudian menggunakan Pengontrol Anda untuk mengambil daftar Hamburgers yang diperlukan , dan meneruskan objek tersebut ke Tampilan (kotak kombo) untuk ditampilkan. Ketika pengguna Anda telah memilih hamburger mana, Anda kemudian dapat meneruskan Hamburgerobjek kembali ke Controller untuk diproses.

Intinya adalah, Anda masih dapat menguji unit Hamburgerlogika "fetch s" dan "proses Hamburger" secara terpisah dari tampilan hamburger yang sebenarnya.