Apakah ini hal yang sama dengan 'ViewModel' dari pola desain Model-View-ViewModel (MVVM)
Nggak.
Itu akan menjadi ini :
Itu memiliki siklus. Paman Bob dengan hati-hati menghindari siklus .
Alih-alih Anda memiliki ini:
Yang pasti tidak memiliki siklus. Tapi itu membuat Anda bertanya-tanya bagaimana pandangan tahu tentang pembaruan. Kita akan membahasnya sebentar lagi.
atau apakah itu Data Transfer Object (DTO) yang sederhana?
Mengutip Bob dari halaman sebelumnya:
Anda dapat menggunakan struct dasar atau objek transfer data sederhana jika Anda mau. Atau Anda bisa mengemasnya ke dalam hashmap, atau membuatnya menjadi sebuah objek.
Arsitektur Bersih p207
Jadi, tentu saja, jika Anda suka.
Tapi saya sangat curiga apa yang sebenarnya mengganggu Anda adalah ini :
Penyalahgunaan kecil yang lucu dari UML ini kontras arah ketergantungan kode sumber dengan arah aliran kontrol. Di sinilah jawaban untuk pertanyaan Anda dapat ditemukan.
Dalam hubungan menggunakan:
aliran kontrol berjalan ke arah yang sama dengan ketergantungan kode sumber.
Dalam hubungan pelaksana:
aliran kontrol biasanya berjalan berlawanan arah dengan ketergantungan kode sumber.
Yang berarti Anda benar-benar melihat ini:
Anda harus dapat melihat bahwa aliran kontrol tidak akan pernah beralih dari Presenter ke View.
Bagaimana itu bisa terjadi? Apa artinya?
Ini berarti view memiliki thread sendiri (yang tidak biasa) atau (seperti yang ditunjukkan oleh @Euphoric) aliran kontrol datang ke tampilan dari sesuatu yang tidak digambarkan di sini.
Jika itu adalah utas yang sama maka View akan tahu kapan View-Model siap dibaca. Tetapi jika itu yang terjadi dan tampilan adalah GUI maka itu akan mengalami kesulitan mengecat ulang layar ketika pengguna memindahkannya sementara mereka menunggu DB.
Jika tampilan memiliki utasnya sendiri maka ia memiliki aliran kontrol sendiri. Itu berarti untuk mengimplementasikan ini, View harus menyurvei View-Model untuk melihat perubahan.
Karena Presenter tidak tahu View itu ada dan View tidak tahu Presenter itu ada, mereka tidak bisa saling memanggil. Mereka tidak bisa saling melemparkan acara. Yang bisa terjadi adalah Presenter akan menulis ke View-Model dan View akan membaca View-Model. Setiap kali terasa seperti itu.
Menurut diagram ini, satu-satunya bagian View dan Presenter berbagi adalah pengetahuan tentang View-Model. Dan itu hanya struktur data. Jadi jangan berharap itu memiliki perilaku.
Itu mungkin tampak mustahil tetapi dapat dibuat untuk bekerja bahkan jika View-Model itu kompleks. Satu bidang kecil yang diperbarui adalah semua tampilan harus polling untuk mendeteksi perubahan.
Sekarang tentu saja Anda dapat bersikeras menggunakan pola pengamat, atau meminta kerangka kerja menyembunyikan masalah ini dari Anda, tetapi harap dipahami bahwa Anda tidak harus melakukannya.
Inilah sedikit kesenangan yang saya ilustrasikan pada aliran kontrol:
Perhatikan bahwa setiap kali Anda melihat aliran berlawanan dengan arah yang saya tentukan sebelumnya, apa yang Anda lihat adalah panggilan balik. Trik itu tidak akan membantu kita sampai ke View. Baiklah, kecuali kita pertama kembali ke apa pun yang disebut Controller. Atau Anda bisa saja mengubah desainnya sehingga Anda bisa mendapatkan tampilan. Itu juga memperbaiki apa yang tampak seperti awal dari masalah yo-yo dengan Akses Data dan Antarmuka itu.
Satu-satunya hal lain yang perlu dipelajari di sini selain itu adalah Use Case Interactor dapat memanggil banyak hal dalam urutan apa pun yang diinginkan asalkan memanggil presenter yang terakhir.